Bu başvuru mimarisi merkezi paylaşılan hizmetleri kullanan, şirket içi bağlantıya ihtiyaç duyan ve bir kuruluşun diğer iş yükleriyle tümleştirilen görev açısından kritik bir iş yükünü dağıtmaya yönelik rehberlik sağlar. Bu kılavuz, kuruluştaki bir uygulama ekibinin parçası olan bir iş yükü sahibine yöneliktir.
Kuruluşunuz iş yükünü Corp. Management grubunu devralan bir Azure uygulama giriş bölgesine dağıtmak istediğinde kendinizi bu durumda bulabilirsiniz. İş yükünün, merkezi ekipler tarafından yönetilen Azure platformu giriş bölgesindeki önceden sağlanan paylaşılan kaynaklarla tümleştirilmesi beklenir.
Önemli
Azure giriş bölgesi nedir? Uygulama giriş bölgesi, iş yükünün çalıştığı bir Azure aboneliğidir. Kuruluşun paylaşılan kaynaklarına bağlıdır. Bu bağlantı aracılığıyla ağ, kimlik erişim yönetimi, ilkeler ve izleme gibi iş yükünü çalıştırmak için gereken temel altyapıya erişimi vardır. Platform giriş bölgeleri, her biri belirli bir işleve sahip çeşitli aboneliklerden oluşan bir koleksiyondur. Örneğin, Bağlan ivity aboneliği, uygulama ekipleri tarafından kullanılabilen merkezi DNS çözümlemesi, şirket içi bağlantı ve ağ sanal gereçleri (NVA) sağlar.
İş yükü sahibi olarak, paylaşılan kaynakların yönetimini merkezi ekiplere devrederek ve iş yükü geliştirme çalışmalarına odaklanarak avantaj sağlarsınız. Kuruluş, tutarlı idare uygulayarak ve maliyetleri birden çok iş yükünde amorti ederek avantaj sağlar.
Azure giriş bölgeleri kavramını anlamanız kesinlikle önerilir.
Bu yaklaşımda maksimum güvenilirlik, siz ve platform ekibi arasında paylaşılan bir sorumluluktır. Merkezi olarak yönetilen bileşenlerin, görev açısından kritik bir iş yükünün beklendiği gibi çalışması için son derece güvenilir olması gerekir. İş yükünü etkileyen merkezi hizmetlerde kullanılamama sorunlarının platform düzeyinde azaltılması için platform ekibiyle güvenilir bir ilişkinize sahip olmanız gerekir. Ancak ekibiniz, hedeflerinize ulaşmak için platform ekibiyle gereksinimleri yönlendirmekle sorumludur.
Bu mimari, ağ denetimleriyle görev açısından kritik temel mimariyi temel alır. Bu makaleye devam etmeden önce temel mimariyi tanımanız önerilir.
Dekont
Kılavuz, Azure'da görev açısından kritik uygulama geliştirmeyi gösteren üretim sınıfı örnek bir uygulama tarafından desteklenir. Bu uygulama, üretime yönelik ilk adımınız olarak daha fazla çözüm geliştirme için temel olarak kullanılabilir.
Temel tasarım stratejileri
Bu stratejileri görev açısından kritik temelin üzerine uygulayın:
Kritik yol
Mimarinin tüm bileşenlerinin eşit derecede güvenilir olması gerekmez. Kritik yol, iş yükünün çalışmama süresi veya düşük performansla karşılaşmaması için işlevsel tutulması gereken bileşenleri içerir. Bu yolu yalın tutmak hata noktalarını en aza indirir.
Bileşenlerin yaşam döngüsü
Neredeyse sıfıra yakın çalışma süresi elde etme hedefinizi etkilediğinden kritik bileşenlerin yaşam döngüsünü göz önünde bulundurun. Bileşenler, gerektiğinde oluşturulup yok edilebilen kısa ömürlü veya kısa ömürlü kaynaklar olabilir; yaşam ömrünü sistem veya bölgeyle paylaşan kısa ömürlü olmayan veya uzun ömürlü kaynaklar.
Dış bağımlılıklar
Hata noktalarına neden olabilecek bileşenler ve işlemler üzerindeki dış bağımlılıkları en aza indirin. Mimari, ekibiniz dışındaki çeşitli ekiplere ait kaynaklara sahiptir. Bu bileşenler (kritikse) bu mimarinin kapsamındadır.
Abonelik topolojisi
Azure giriş bölgeleri tek bir abonelik topolojisi anlamına gelmez. Tüm ortamlarda iş yükü güvenilirlik gereksinimlerini karşılamak için platform ekibinizle abonelik ayak izinizi önceden planlayın.
Kritik yolda otonom gözlemlenebilirlik
Ekibin veri toplamalarını (özellikle kritik yolu) hızlı bir şekilde sorgulamasını ve düzeltmeler üzerinde işlem yapmasını sağlayan ayrılmış izleme kaynaklarına sahip olun.
Mimari
Bu mimarinin bir Visio dosyasını indirin.
Bu mimarinin bileşenleri, ağ denetimlerine sahip görev açısından kritik temel mimariyle aynıdır. Açıklamalar kısa ve kısadır. Daha fazla bilgiye ihtiyacınız varsa bağlantılı makalelere bakın. Azure hizmetleri hakkındaki ürün belgeleri için bkz . İlgili kaynaklar.
Genel kaynaklar
Bu kaynaklar uygulama giriş bölgesi aboneliklerinde yer alır. Genel kaynaklar kısa ömürlü değil ve sistemin ömrünü paylaşıyor. Azure hizmetleri ve yapılandırmaları temel genel kaynaklarda olduğu gibi kalır.
Bölgesel ağ kaynakları
Bu kaynaklar platform giriş bölgesi abonelikleri ve uygulama giriş bölgesi abonelikleri arasında yer alır. Temel mimari, sahip olduğunuz tüm kaynakları dağıtır. Ancak bu mimaride ağ kaynakları, platform giriş bölgesinin bir parçası olarak Bağlan ivity aboneliği aracılığıyla sağlanır.
Bu makalede Bölgesel merkez sanal ağı bölümüne bakın.
Bölgesel damga kaynakları
Bu kaynaklar uygulama giriş bölgesi aboneliklerinde yer alır. Bu kaynaklar, genel kaynaklar dışında diğer kaynaklarla hiçbir şey paylaşmaz.
Çoğu Azure hizmeti ve yapılandırması, platform ekibi tarafından önceden sağlanan ağ kaynakları dışında temel damga mimarisiyle aynı kalır.
Bu makalede Bölgesel uç sanal ağı bölümüne bakın.
Dış kaynaklar
İş yükü şirket içi kaynaklarla etkileşim kurar. Bazıları iş yükü için kritik yoldadır, örneğin şirket içi veritabanı. Bu kaynaklar ve onlarla iletişim, iş yükünün genel bileşik Hizmet Düzeyi Sözleşmesi'ne (SLA) dahil edilir. Tüm iletişimler Bağlan ivity aboneliği üzerinden yapılır. İş yükünün ulaşabileceği başka dış kaynaklar da vardır ancak bunlar kritik olarak kabul edilmez.
Dağıtım işlem hattı kaynakları
Görev açısından kritik bir uygulama için derleme ve yayın işlem hatları, doğrulanmış bir damga pulu dağıtmanın tutarlı bir yolunu garanti etmek için tam olarak otomatikleştirilmelidir. Bu kaynaklar temel dağıtım işlem hattıyla aynı kalır.
Bölgesel izleme kaynakları
Bu kaynaklar uygulama giriş bölgesi aboneliklerinde yer alır. Genel kaynaklar ve bölgesel kaynaklar için izleme verileri bağımsız olarak depolanır. Azure hizmetleri ve yapılandırmaları temel izleme kaynaklarıyla aynı kalır.
Bu makalede İzlemeyle ilgili dikkat edilmesi gerekenler bölümüne bakın.
Yönetim kaynakları
Özel işlem kümesine ve diğer kaynaklara erişim elde etmek için bu mimaride özel derleme aracıları ve atlama kutusu sanal makineleri örnekleri kullanılır. Azure Bastion, atlama kutularına güvenli erişim sağlar. Damgaların içindeki kaynaklar temel yönetim kaynaklarıyla aynı kalır.
Ağ konusunda dikkat edilmesi gerekenler
Bu tasarımda, iş yükü uygulama giriş bölgesine dağıtılır ve platform giriş bölgesindeki federasyon kaynaklarına bağlanması gerekir. Amaç şirket içi kaynaklara erişmek, çıkış trafiğini denetlemek vb. olabilir.
Ağ topolojisi
Tüm kuruluş için ağ topolojisine platform ekibi karar verir. Bu mimaride merkez-uç topolojisi varsayılır. Alternatif olarak Azure Sanal WAN kullanılabilir.
Bölgesel merkez sanal ağı
Bağlan ivity aboneliği, tüm kuruluş tarafından paylaşılan kaynakları içeren bir merkez sanal ağı içerir. Bu kaynaklar platform ekibine aittir ve bunların bakımına sunulur.
Görev açısından kritik bir perspektiften bakıldığında, bu ağ kısa ömürlü değildir ve bu kaynaklar kritik yoldadır.
| Azure kaynağı | Amaç |
|---|---|
| Azure ExpressRoute | Şirket içinden Azure altyapısına özel bağlantı sağlar. |
| Azure Güvenlik Duvarı | Çıkış trafiğini inceleyen ve kısıtlayan NVA işlevi görür. |
| Azure DNS | Şirket içi şirket içi ad çözümlemesi sağlar. |
| VPN Gateway | Bağlan uzak kuruluş, genel İnternet üzerinden Azure altyapısına dallar. Ayrıca dayanıklılık eklemek için yedek bağlantı alternatifi olarak da görev yapar. |
Kaynaklar her bölgede sağlanır ve uç sanal ağına eşlenir (bundan sonra açıklanmıştır). NVA güncelleştirmelerini, güvenlik duvarı kurallarını, yönlendirme kurallarını, ExpressRoute'u VPN Gateway'e, DNS altyapısına vb. yük devretmeyi anladığınızdan ve kabul ettiğinizden emin olun.
Dekont
Federasyon hub'ını kullanmanın temel avantajlarından biri, iş yükünün kuruluş tarafından yönetilen ağ hub'larından geçiş yaparak Azure'daki diğer iş yükleriyle veya çapraz şirket içi iş yükleriyle tümleştirilebiliyor olmasıdır. Sorumluluğun bir kısmı platform ekibine kaydırıldığından bu değişiklik operasyonel maliyetlerinizi de düşürür.
Bölgesel uç sanal ağı
Uygulama giriş bölgesinde bölge başına bölgesel damgalar tarafından başvurulan, önceden sağlanmış en az iki Azure Sanal Ağ vardır. Bu ağlar kısa ömürlü değil. Biri üretim trafiğine hizmet ederken diğeri vNext dağıtımını hedefler. Bu yaklaşım size güvenilir ve güvenli dağıtım uygulamaları gerçekleştirme olanağı sağlar.
İşletim sanal ağı
İşletimsel trafik ayrı bir sanal ağda yalıtılır. Bu sanal ağ kısa ömürlü değildir ve bu ağın sahibi sizsiniz. Bu mimari, ağ denetimleriyle temel mimariyle aynı tasarımı korur.
İşlem ağı ile uç ağı arasında eşleme yoktur. Tüm iletişim Özel Bağlantı üzerinden yapılır.
Paylaşılan sorumluluklar
Mimarinin her tasarım öğesinden hangi ekibin sorumlu olduğunu net bir şekilde anlamayı öğrenin. Bazı önemli alanlar aşağıdadır.
IP adresi planlaması
İş yükünüzü çalıştırmak için gereken boyutu tahmin ettikten sonra, ağı uygun şekilde sağlayabilmeleri için platform ekibiyle birlikte çalışın.
Platform ekibi
Eşlemelere katılan sanal ağlar için ayrı adresler sağlayın. Şirket içi ve iş yükü ağları gibi çakışan adresler kesintiye neden olabilir.
Çalışma zamanı ve dağıtım kaynaklarını içerecek kadar büyük IP adresi alanları ayırın, yük devretmeleri işleyin ve ölçeklenebilirliği destekleyin.
Önceden sağlanan sanal ağ ve eşlemelerin iş yükünün beklenen büyümesini destekleyebilmesi gerekir. Bu büyümeyi platform ekibiyle düzenli olarak değerlendirmeniz gerekir. Daha fazla bilgi için bkz. Azure'a Bağlan üretkenlik.
Bölgesel uç ağı alt ağı
Bölgesel sanal ağda alt ağları ayırma sorumluluğunuz vardır. Alt ağlar ve içindeki kaynaklar kısa ömürlü olur. Adres alanı, potansiyel büyümeyi karşılayacak kadar büyük olmalıdır.
Özel uç noktalar alt ağı Trafik sanal ağa ulaştıktan sonra ağ içindeki PaaS hizmetleriyle iletişim, ağ denetimleriyle temel mimaride olduğu gibi özel uç noktalar kullanılarak kısıtlanır. Bu uç noktalar ayrılmış bir alt ağa yerleştirilir. Özel uç noktalara özel IP adresleri bu alt ağdan atanır.
Küme alt ağı İş yükünün ölçeklenebilirlik gereksinimleri, alt ağlar için ne kadar adres alanı ayrılması gerektiğini etkiler. AKS düğümlerinin ve podlarının ölçeği genişletildikçe, IP adresleri bu alt ağdan atanır.
Ağ segmentasyonu
İş yükünüzün güvenilirliğinin yetkisiz erişimden etkilenmemesi için uygun segmentlere ayırmayı koruyun.
Bu mimaride, alt ağlar ve Bağlan ivity aboneliği genelinde trafiği kısıtlamak için Ağ Güvenlik Grupları (NSG) kullanılır. NSG'ler desteklenen hizmetler için ServiceTags kullanır.
Platform ekibi
Azure Ağ Yöneticisi İlkeleri aracılığıyla NSG kullanımını zorunlu kılma.
İş yükü tasarımına dikkat edin. Damga pulları arasında doğrudan trafik yok. Ayrıca bölgeler arası akışlar da yoktur. Bu yollar gerekiyorsa trafiğin Bağlan ivity aboneliğinde akması gerekir.
Görev açısından kritik iş yüküne diğer iş yüklerinden kaynaklanan gereksiz hub trafiğini önleyin.
Bölgesel damga pullarından çıkış trafiği
Her bölgesel uç ağından giden tüm trafik, bölgesel merkez ağındaki merkezi Azure Güvenlik Duvarı yönlendirilir. Trafiği inceleyen ve ardından trafiğe izin veren veya trafiği reddeden sonraki atlama işlevi görür.
Platform ekibi
Bu özel yol için UDR'ler oluşturun.
Uygulama ekibinin yeni yol tablosu olmayan alt ağlar oluşturmasını engelleyecek Azure ilkeleri atayın.
İş yükünün gereksinimlerine göre yolları genişletebilmeleri için uygulama ekibine yeterli rol tabanlı erişim denetimi (RBAC) izinleri verin.
Çok bölgeli yedeklilik
Bölgesel kesintilere dayanabilmek için görev açısından kritik iş yüklerinizin birden çok bölgeye dağıtılması gerekir. Altyapının güvenilir olduğundan emin olmak için platform ekibiyle birlikte çalışın.
Platform ekibi
Bölge başına merkezi ağ kaynakları dağıtma. Görev açısından kritik tasarım metodolojisi bölgesel yalıtım gerektirir.
Bir bölgedeki düşürülmüş platform kaynağının başka bir bölgedeki iş yüklerini etkilememesi için gizli bölgesel bağımlılıkları ortaya çıkarmak için uygulama ekibiyle birlikte çalışın.
DNS çözümleme
Bağlan ivity aboneliği özel DNS bölgeleri sağlar. Ancak bu merkezi yaklaşım, kullanım örneğinize özgü olabilecek DNS gereksinimlerini dikkate almayabilir. Kendi DNS bölgelerinizi sağlayın ve bölgesel damgaya bağlanın. Uygulama ekibi DNS'ye sahip değilse, Azure Cosmos DB gibi genel kaynaklar için özel bağlantıların yönetimi zorlaşır.
Platform ekibi
Kullanım örneklerini karşılamak için Azure Özel DNS bölgelerini uygulama ekibine devretme.
Bölgesel merkez ağı için, uygulama ekibi tarafından yönetilen özel DNS bölgelerini desteklemek için DNS sunucuları değerini Varsayılan (Azure tarafından sağlanan) olarak ayarlayın.
Ortam tasarımında dikkat edilmesi gerekenler
İş yüklerini üretim, üretim öncesi ve geliştirme için ayrı ortamlara yerleştirmek genel bir uygulamadır. Önemli noktalardan bazıları aşağıdadır.
Yalıtım nasıl korunur?
Üretim ortamı diğer ortamlardan yalıtılmalıdır . Daha düşük ortamlar da yalıtım düzeyini korumalıdır. Uygulamaya ait kaynakları ortamlar arasında paylaşmaktan kaçının.
Uygulama ekibinin sahip olduğu küresel, bölgesel ve damga kaynakları için bir üretim ortamı gereklidir. Hazırlama ve tümleştirme gibi üretim öncesi ortamlar, uygulamanın mümkün olduğunca üretim simülasyonu yapılan bir ortamda test edilmesi için gereklidir. Geliştirme ortamı, üretimin ölçeği azaltılmış bir sürümü olmalıdır.
Beklenen yaşam döngüsü nedir?
Doğrulama testleri tamamlandıktan sonra üretim öncesi ortamlar yok edilebilir. Geliştirme ortamlarının bir özelliğin ömrünü paylaşması ve geliştirme tamamlandığında yok edilmesi önerilir. Sürekli tümleştirme/sürekli dağıtım (CI/CD) otomasyonu tarafından gerçekleştirilir.
Dezavantajlar nelerdir?
Ortamların yalıtımı, yönetimin karmaşıklığı ve maliyet iyileştirme arasındaki dengeleri göz önünde bulundurun.
Bahşiş
Tüm ortamlar, platform kaynakları dahil olmak üzere dış kaynakların üretim örneklerine bağımlılıklar almalıdır. Örneğin, Bağlan ivity aboneliğindeki bir üretim bölgesel hub'ı. Üretim öncesi ve üretim ortamları arasındaki değişimleri en aza indirebileceksiniz.
İş yükü altyapısı için abonelik topolojisi
Abonelikler platform ekibi tarafından size verilir. Ortam sayısına bağlı olarak, yalnızca bir iş yükü için birkaç abonelik istemeniz gerekir. Ortamın türüne bağlı olarak, bazı ortamların ayrılmış aboneliklere ihtiyacı olabilirken, diğer ortamlar tek bir abonelikte birleştirilebilir.
Ne olursa olsun, iş yükü için genel güvenilirlik hedefini karşılayan bir topoloji tasarlamak için platform ekibiyle birlikte çalışın. Üretim ortamını yansıtacağından platform tarafından sağlanan kaynakları aynı abonelikteki ortamlar arasında paylaşmanın avantajı vardır.
Dekont
Ortamları içermek için birden çok abonelik kullanmak, gerekli yalıtım düzeyine ulaşabilir. Giriş bölgesi abonelikleri aynı yönetim grubundan devralınır. Bu nedenle test ve doğrulama için üretimle tutarlılık sağlanır.
Üretim aboneliği
Size verilen abonelikte kaynak sınırları olabilir. Tüm bu kaynakları tek bir abonelikte birlikte kullanırsanız bu sınırlara ulaşabilirsiniz. Ölçek birimlerinize ve beklenen ölçeğe göre daha dağıtılmış bir model düşünün. Örneğin:
Hem Azure DevOps derleme aracılarını hem de genel kaynakları içeren bir abonelik.
Bölge başına bir abonelik. Bölgesel kaynakları, damga kaynaklarını ve bölgesel damga pulları için sıçrama kutularını içerir.
Aşağıda, bu mimaride kullanılan örnek bir abonelik topolojisi verilmiştır.
Üretim öncesi abonelik
En az bir abonelik gereklidir. Birçok bağımsız ortam çalıştırabilir, ancak ayrılmış aboneliklerde birden çok ortam olması önerilir. Bu abonelik, yukarıda açıklanan üretim aboneliği gibi kaynak sınırlarına da tabi olabilir.
Geliştirme aboneliği
En az bir abonelik gereklidir. Tüm bağımsız ortamlar çalıştırılırsa bu abonelik kaynak sınırlarına tabi olabilir. Bu nedenle, birden çok abonelik isteyebilirsiniz. Ayrılmış aboneliklerinde tek tek ortamlar olması önerilir.
Üretim topolojisini mümkün olduğunca eşleştirmeyi deneyin.
Dağıtma konuları
Başarısız dağıtımlar veya hatalı sürümler, uygulama kesintilerinin yaygın nedenleridir. Uygulamanızı (ve yeni özellikleri) uygulama yaşam döngüsünün bir parçası olarak kapsamlı bir şekilde test edin. İş yükünü giriş bölgesine dağıtırken tasarımınızı platform tarafından sağlanan kaynaklar ve idareyle tümleştirmeniz gerekir.
Bkz. İyi tasarlanmış görev açısından kritik iş yükleri: Dağıtım ve test.
Dağıtım altyapısı
Derleme aracıları ve ağları gibi dağıtım altyapısının güvenilirliği genellikle iş yükünün çalışma zamanı kaynakları kadar önemlidir.
Bu mimari, uygulamanın kullanılabilirliğini etkileyebilecek yetkisiz erişimi önlemek için özel derleme aracılarını kullanır.
Dağıtım kaynakları arasında yalıtımın korunması kesinlikle önerilir. Dağıtım altyapısı, bu ortam için iş yükü aboneliklerinize bağlı olmalıdır. Üretim öncesi aboneliklerde birden çok ortam kullanıyorsanız, erişimi yalnızca tek tek ortamlarla sınırlayarak daha fazla ayrım oluşturun. Dağıtım altyapısını daha güvenilir hale getirmek için bölge başına dağıtım kaynakları düşünülebilir.
Sıfır kapalı kalma süresi dağıtımı
Uygulamaya Güncelleştirmeler kesintilere neden olabilir. Tutarlı dağıtımları zorunlu tutma güvenilirliği artırır. Bu yaklaşımlar önerilir:
- Tam otomatik dağıtım işlem hatlarına sahip olun.
- Güncelleştirmeleri temiz bir damga üzerinde üretim öncesi ortamlarda dağıtın.
Daha fazla bilgi için bkz . Görev açısından kritik dağıtım ve test yönergeleri.
Temel mimaride, bu stratejiler sağlamanın kaldırılması ve her güncelleştirmeyle damganın kaldırılmasıyla uygulanır. Bu tasarımda, platform ekibi bazı kaynaklara sahip olduğundan tam sağlamayı kaldırma mümkün değildir. Bu nedenle dağıtım modeli değiştirildi.
Dağıtım modeli
Temel mimari, uygulama güncelleştirmelerini dağıtmak için Mavi-Yeşil modelini kullanır. Değişiklikler içeren yeni damga pulları mevcut damga pullarıyla birlikte dağıtılır. Trafik yeni damgaya taşındıktan sonra mevcut damga yok edilir.
Bu durumda, belirli eşlenen sanal ağ kısa ömürlü değildir. Damga damgasının sanal ağı veya bölge hub'ına eşlemeyi oluşturmasına izin verilmez. Bu kaynakları her dağıtımda yeniden kullanmanız gerekir.
Kanarya modeli, geri alma seçeneğiyle güvenli dağıtıma ulaşabilir. İlk olarak, kod değişiklikleriyle yeni bir damga dağıtılır. Dağıtım işlem hattı önceden sağlanan sanal ağa başvurur ve alt ağları ayırır, kaynakları dağıtır, özel uç noktalar ekler. Ardından, önceden sağlanan bu sanal ağda trafiği bu alt ağlara kaydırıyor.
Mevcut damga artık gerekli olmadığında, platforma ait kaynaklar dışında tüm damga kaynakları işlem hattı tarafından silinir. Sanal ağ, tanılama ayarları, eşleme, IP adresi alanı, DNS yapılandırması ve rol tabanlı erişim denetimi (RBAC) korunur. Bu noktada damga temiz durumdadır ve sonraki yeni dağıtım için hazırdır.
DINE (mevcut değilse dağıt) Azure ilkeleri
Azure uygulama giriş bölgeleri DINE (mevcut değilse dağıt) Azure ilkelerine sahip olabilir. Bu denetimler, dağıtılan kaynakların uygulama ekibine ait olsalar bile uygulama giriş bölgelerindeki kurumsal standartlara uygun olmasını sağlar. Dağıtımınız ile son kaynak yapılandırması arasında bir uyuşmazlık olabilir.
Kaynaklarınıza uygulanacak tüm DINE ilkelerinin etkisini anlayın. Kaynak yapılandırmasında değişiklikler varsa, ilkelerin amacını iş yükünün geliştirme döngüsünün başlarında bildirim temelli dağıtımlarınıza ekleyin. Aksi takdirde, istenen durum ile dağıtılan durum arasında deltaya yol açan bir kayma olabilir.
Dağıtım aboneliği erişim yönetimi
Patlama yarıçapını sınırlamak için abonelik sınırlarını güvenlik sınırlarınız olarak değerlendirin. Tehditler iş yükünün güvenilirliğini etkileyebilir.
Platform ekibi
- Uygulama ekiplerine uygulama giriş bölgesi aboneliği kapsamındaki izinlere sahip işlemler için yetkilendirme verin.
Tek bir abonelik içinde birden çok dağıtım çalıştırıyorsanız, bir ihlal her iki dağıtımı da etkiler. Dağıtımların ayrılmış aboneliklerde çalıştırılması önerilir. Mantıksal ayrımı korumak için ortam başına hizmet sorumluları oluşturun.
Hizmet sorumlusu, iş yükü kaynakları üzerinde özerklik sağlamalıdır. Ayrıca, abonelik içindeki platform kaynaklarının aşırı manipülasyonunu önleyecek kısıtlamalara sahip olmalıdır.
İzlemeyle ilgili dikkat edilmesi gerekenler
Azure giriş bölgesi platformu, Yönetim aboneliklerinin bir parçası olarak paylaşılan gözlemlenebilirlik kaynakları sağlar. Merkezi operasyon ekibi , uygulama ekiplerini federasyon modelini kullanmaya teşvik etti. Ancak görev açısından kritik iş yükleri için tek bir hata noktası olabileceğinden tek bir merkezi gözlemlenebilirlik deposu önerilmez. Görev açısından kritik iş yükleri, merkezi operasyon ekipleri için geçerli veya eyleme dönüştürülebilir olmayabilecek telemetri verileri de oluşturur.
Bu nedenle, izleme için otonom bir yaklaşım kesinlikle önerilir. İş yükü operatörleri sonuçta izlemeden sorumludur ve genel durumu temsil eden tüm verilere erişim sahibi olmalıdır.
Temel mimari bu yaklaşımı izler ve bu başvuru mimarisinde devam eder. Azure Log Analytics ve Azure Uygulaması Analizler, bu kapsamlardaki kaynakları izlemek için bölgesel ve küresel olarak dağıtılır. Günlükleri toplama, pano oluşturma ve uyarı oluşturma, ekibiniz için kapsam dahilindedir. Günlük ve ölçüm toplama platform gereksinimlerini desteklemek için çeşitli havuzlara ölçüm ve günlük gönderen Azure Tanılama özelliklerinden yararlanın.
Sistem durumu modeli
Görev açısından kritik tasarım metodolojisi bir sistem durumu modeli gerektirir. Genel bir sistem durumu puanı tanımlarken, uygulamanın bağımlı olduğu kapsam içi platform giriş bölgesi akışlarını ekleyin. Çalışma alanları arası izleme gerçekleştirmek için günlük, sistem durumu ve uyarı sorguları oluşturun.
Platform ekibi
Görev açısından kritik uygulamanın kritik yolunda kullanılan ilgili platform kaynakları için rol tabanlı erişim denetimi (RBAC) sorgusu ve okuma günlük havuzları verin.
Uygulama ekibine işlemlerini yapmak için yeterli izin vererek görev açısından kritik iş yüküne yönelik kurumsal güvenilirlik hedefini destekleyin.
Bu mimaride sistem durumu modeli, Bağlan ivity aboneliğinde sağlanan kaynaklardan günlükleri ve ölçümleri içerir. Bu tasarımı veritabanı gibi şirket içi bir kaynağa ulaşmak için genişletirseniz sistem durumu modeli, Azure'daki ve şirket içindeki ağ sanal gereçleri gibi güvenlik sınırları da dahil olmak üzere bu kaynağa ağ bağlantısını içermelidir. Bu bilgiler, kök nedeni hızla belirlemek ve güvenilirlik etkisini düzeltmek için önemlidir. Örneğin, veritabanına yönlendirmeye çalışırken hata oluştu mu yoksa veritabanıyla ilgili bir sorun mu oluştu?
Bkz. İyi tasarlanmış görev açısından kritik iş yükleri: Sistem durumu modelleme.
Platform tarafından sağlanan ilkeler ve kurallarla tümleştirme
Uygulama giriş bölgesi aboneliği, Yönetim grubundan Azure ilkelerini, Azure Ağ Yöneticisi kurallarını ve diğer denetimleri devralır. Platform ekibi bu korumaları sağlar.
Dağıtımlar için, platform tarafından sağlanan ilkelere özel olarak bağımlı değildir, çünkü:
- Bunlar, tek tek iş yüklerinin gereksinimlerini karşılayacak şekilde tasarlanmamıştır.
- İlkeler ve kurallar güncelleştirilebilir veya ekibinizin dışından kaldırılabilir ve bu nedenle güvenilirliği etkileyebilir.
Dağıtımlarınızda Azure ilkeleri oluşturmanız ve atamanız kesinlikle önerilir. Bu çaba, sistemin güvenilirliği üzerindeki olası etki göz önünde bulundurularak bazı yinelemelere yol açabilir ancak bu kabul edilebilir bir durumdur. Platform ilkelerinde değişiklikler varsa, iş yükü ilkeleri yerel olarak geçerli olmaya devam eder.
Platform ekibi
- Uygulama ekibini, geliştikçe ilkelerin değişiklik yönetimi sürecine dahil edin.
- Uygulama ekibi tarafından kullanılan ilkelere dikkat edin. Yönetim grubuna eklenmesi gerekip gerekmediğini değerlendirin.
Bu mimariyi dağıt
Bu mimarinin ağ özellikleri, Görev açısından kritik Bağlan uygulamada uygulanır.
Dekont
Bağlan uygulama, kuruluş kaynaklarına dayalı, diğer iş yükleriyle tümleşen ve paylaşılan hizmetleri kullanan görev açısından kritik bir iş yükünü göstermek için tasarlanmıştır. Uygulama, bir Bağlan ivity aboneliğinin zaten mevcut olduğunu varsayar.
Sonraki adımlar
Azure İyi Tasarlanmış Çerçeve'de ağ ve bağlantı tasarım alanını gözden geçirin.
İlgili kaynaklar
Temel mimaride kullanılan Azure hizmetlerine ek olarak, bu hizmetler bu mimari için önemlidir.