Azure giriş bölgeleri için bağımsız yazılım satıcısı (ISV) konuları
Birçok kuruluş için Azure giriş bölgeleri kavramsal mimarisi, bulut benimseme yolculuğunun hedefini temsil eder. Giriş bölgeleri, birden çok aboneliğe sahip bir Azure ortamı oluşturmayı açıklar. Her giriş bölgesi ölçek, güvenlik, idare, ağ ve kimlik bilgilerini hesaplar ve birçok müşteriden alınan geri bildirimlere ve derslere dayanır.
Bahşiş
Azure giriş bölgelerini şehir planları gibi düşünmek yararlı olabilir. Giriş bölgesine dağıtılan iş yüklerinin mimarileri, bir şehirdeki binaların planlarına benzer.
Bir şehrin su, gaz, elektrik ve ulaşım sistemlerinin tümünün bina inşa edilebilmesi için önce yerinde olması gerekir. Benzer şekilde, bir Azure giriş bölgesinin yönetim grupları, ilkeler, abonelikler ve rol tabanlı erişim denetimi (RBAC) dahil olmak üzere bileşenlerinin, tüm üretim iş yüklerinin dağıtılabilmesi için önce yerinde olması gerekir.
Bağımsız bir yazılım satıcısı (ISV) çözümünüzü Azure'da oluşturup çalıştırırken Azure ortamınızı oluştururken aşağıdaki kaynaklara başvurmanız gerekir:
- Azure giriş bölgeleri: Genel Azure ortamınız için rehberlik sağlar.
- Azure İyi Tasarlanmış Çerçeve: Tüm iş yükleri için geçerli mimari rehberlik sağlar.
- Azure'da çok kiracılı çözümler tasarlama: Azure'da çok kiracılı çözümler için özel mimari rehberlik sağlar.
Azure giriş bölgeleri, genel Azure ortamınız için bir yön seçmenize yardımcı olur. Ancak BIR ISV, SaaS sağlayıcısı veya başlatma olarak, belirli uygulama gereksinimleriniz daha standart müşteri senaryolarından farklı olabilir. Aşağıda yalnızca birkaç farklı uygulama senaryosu örneği verilmiştir:
- Müşterilerin kendi aboneliklerine dağıttığı yazılımlar oluşturursunuz.
- Kendi denetim düzleminiz var ve SaaS çözümleriniz için Azure kaynaklarını dağıtmak ve yapılandırmak için otomasyon betiklerini veya yazılımlarını kullanıyorsunuz.
- Küçük bir ISV veya startup'sınız ve mümkün olan en düşük maliyetle başlamak istiyorsunuz ve başlangıçta Azure Güvenlik Duvarı ve Azure DDoS Koruması gibi hizmetleri kullanmak istemeyebilirsiniz.
- Büyük bir SaaS ISV'siniz ve SaaS uygulamanızı ölçek için birden çok aboneliğe bölmeyi planlıyorsunuz. Ayrıca abonelikleri, geliştirme, test, hazırlama ve üretim ortamlarınıza karşılık gelen şekilde gruplandırmak istiyorsunuz.
- Kuruluşunuzun çalışma modeli, kurumsal BT ekibinizin ve SaaS ürün ekiplerinizin rollerini birbirinden ayırır. Kuruluşunuzun kurumsal BT ekibi Microsoft Office 365 ve Microsoft Teams gibi kaynakları yönetebilir ve SaaS ürün ekibiniz SaaS ürününüzü (merkezi platform ve kimlik bileşenleri dahil) oluşturmaktan ve çalıştırmaktan sorumlu olabilir.
Dekont
ISV'ler bazen hem platform "paylaşılan hizmetler" yönlerini hem de gerçek iş yükü kaynaklarını içeren tek bir Azure aboneliğiyle başlamak ister. Bu teknik olarak mümkün olsa da, daha sonra kaynakları abonelikler arasında taşımanız gerektiğinde ve tüm kaynak türlerinin taşınamadığını fark ettiğinizde zorluklarla karşılaşacaksınız. Hangi sapmaların mümkün olduğunu ve bunların çeşitli risk düzeylerini anlamak için tasarım sapmalarının etkisini gözden geçirin.
ISV dağıtım modelleri
ISV çözümleri genellikle üç dağıtım modelinden birine uyar: saf SaaS, müşteri tarafından dağıtılan veya çift dağıtımlı SaaS. Bu bölümde, her modelin Azure giriş bölgeleri için dikkate alınması gereken farklı noktalar açıklanmaktadır.
Saf SaaS
Saf SaaS modelinde, yazılımınız tamamen yalnızca Azure aboneliklerinizde dağıtılır. Son müşteriler yazılımınızı kendi Azure aboneliklerine dağıtmadan tüketir. Aşağıdaki diyagramda, kullanıcılar ISV tarafından sağlanan saf bir SaaS uygulamasını kullanıyor:
Saf SaaS yazılımına örnek olarak hizmet olarak e-posta, hizmet olarak Kafka, hizmet olarak bulut-veri ambarı ve Azure Market birçok SaaS listesi verilebilir.
Küçük bir SaaS ISV'yseniz kaynaklarınızı hemen dağıtmak için birden çok Azure aboneliği kullanmanız gerekmeyebilir. Ancak siz ölçeklendirdikçe Azure'ın abonelik sınırları tek bir abonelik içinde ölçeklendirme yeteneğinizi etkileyebilir. Kurumsal ölçekli giriş bölgesi tasarım ilkelerini, özellikle abonelik demokratikleştirmesini gözden geçirin ve gelecekteki büyümenizi planlamak için çok kiracılı mimari yaklaşımları tanıyın.
Saf SaaS çözümleri oluşturan ISV'ler aşağıdaki soruları dikkate almalıdır:
- SaaS çözümümüzü oluşturan tüm Azure kaynakları tek bir Azure aboneliğinde mi yoksa birden çok Azure aboneliğinde bölümlenmiş mi olmalıdır?
- Her müşteriyi kendi ayrılmış Azure aboneliğinde barındırmalı mı yoksa bir veya birkaç paylaşılan abonelik içinde kaynak oluşturabilir miyiz?
- Çözümümüzün tüm katmanlarına Dağıtım Damgası (ölçek birimi) desenini nasıl uygulayabiliriz?
- Azure kaynak kuruluşunu çok kiracılı çözümlerde kullanarak ölçeklendirme zorlukları ve Azure abonelik sınırlarıyla karşı karşıya kalmamızı nasıl önleyebiliriz?
Müşteri tarafından dağıtılan
Müşteri tarafından dağıtılan modelde, son müşterileriniz sizden yazılım satın alır ve ardından yazılımı kendi Azure aboneliklerine dağıtır. Dağıtımı Azure Market başlatabilir veya yönergeleri izleyerek ve sağladığınız betikleri kullanarak el ile gerçekleştirebilirler.
Aşağıdaki diyagramda ISV bir yazılım paketi veya Azure Market katalog ürünü sağlar ve kullanıcılar bu kaynağı diğer iş yükleriyle birlikte kendi Azure aboneliklerine dağıtır:
Müşterinin diyagramdaki diğer iş yükü öğesi, müşterinin kendi iş yükünü veya müşterinin Azure aboneliği içinde dağıtmış olduğu başka bir ISV ürününü temsil edebilir. Müşteriler genellikle farklı ISV'lerden Azure aboneliklerine birden çok ürün dağıtır. Çözümler oluşturmak için bu ürünleri tek tek bir araya getirirler. Örneğin, bir müşteri bir ISV'den bir veritabanı ürünü, başka bir ISV'den ağ sanal gereci ve üçüncü bir ISV'den bir web uygulaması dağıtabilir.
Müşteri tarafından dağıtılan ISV ürünlerine örnek olarak Azure Market birçok sanal makine görüntüsü (ağ ve depolama sanal gereçleri gibi) ve Azure uygulamaları verilebilir.
Müşteri tarafından dağıtılan bazı çözümler için kuruluş, Azure Lighthouse veya Azure Yönetilen Uygulamaları kullanarak son müşteri Azure abonelikleri içinde dağıtılan çözümün yönetimini ve güncelleştirmelerini sağlayabilir. ISV'ler, Çözüm Tümleştiricileri (SIS) ve Yönetilen Hizmet Sağlayıcılarının (MSP' ler) tümü bu stratejiyi kendi gereksinimlerini karşıladığında kullanabilir.
Müşteri tarafından dağıtılan ISV çözümleri, Azure giriş bölgeleri açısından standart bir uygulama iş yükü olarak kabul edilir. Ürününüzü, Azure müşterilerinizin benimsediği Azure giriş bölgeleri tasarım ilkeleriyle çalışacak şekilde tasarlarken Azure giriş bölgeleri kılavuzunu göz önünde bulundurun.
Mevcut müşterilerinizin iş yüklerini Azure'a geçirirken Azure giriş bölgesi kavramlarını iyi anlamanız özellikle önemlidir.
Müşteri tarafından dağıtılan çözümler oluşturan ISV'ler aşağıdaki soruları dikkate almalıdır:
- Müşteri çözümümüzü kendi ayrılmış aboneliğine mi yoksa ilgili iş yüklerini içeren mevcut bir aboneliğe mi dağıtmalı?
- Müşteriler mevcut iş yükleri (Azure içinde ve dışında) ile çözümümüz arasında nasıl ağ bağlantısı kurmalı?
- Çözümümüz Microsoft Entra Id kimlik doğrulaması mekanizmalarını destekliyor mu yoksa LDAP veya Kerberos gibi başka protokoller mi gerektiriyor?
- Çözüm şablonlarımız ile müşterinin Azure ilkeleri arasındaki çakışmalar gibi Azure İlkesi ihlallerini nasıl azaltabilir veya ortadan kaldırırız?
Azure İlkesi ihlallerine neden olabilecek müşteri Azure ilkeleri, "Tüm alt ağların bir ağ güvenlik grubuna sahip olması gerekir" ve "Corp giriş bölgesindeki ağ arabirimlerine genel IP adresi eklenemez" gibi örnekler içerir. Dağıtımınızı planladığınızda bu çakışmaya neden olan ilkelerin potansiyelini göz önünde bulundurun.
İkili dağıtım SaaS
Bazı SaaS çözümleri, müşterilerin Azure aboneliklerinde dağıtılan kaynaklarla etkileşim kurar veya bunları kullanır. Bu dağıtım modeli bazen çift dağıtım SaaS veya SaaS karma olarak adlandırılır. Aşağıdaki diyagramda ISV, son müşterinin Azure aboneliğine dağıtılan kaynaklarla etkileşim kuran barındırılan bir SaaS çözümü sağlar:
Çift dağıtım SaaS'ye gerçek dünyadan bir örnek olarak, isteğe bağlı olarak müşterinin Azure aboneliğindeki bir sanal makineye dağıtılan bir Power BI şirket içi veri ağ geçidini kullanabilen bir SaaS hizmeti olan Microsoft Power BI'dır.
İkili dağıtım SaaS senaryolarına diğer örnekler şunlardır:
- Kuruluşunuz, her müşterinin Azure aboneliğindeki Azure Sanal Masaüstü kaynaklarını denetlemek için SaaS konsol arabirimi sağlayan bir ürün olan Virtual Desktop Manager'ı oluşturur.
- Kuruluşunuz veri analizi için bir SaaS konsolu sağlar ve her müşterinin Azure aboneliğinde işlem düğümü sanal makinelerini dinamik olarak oluşturur ve siler.
İkili dağıtım ISV olarak, iki alanda rehberlik için Azure giriş bölgesine başvurmanız gerekir: SaaS hizmetinizi barındırmak için kendi Azure ortamınızı yapılandırma ve müşterilerin Azure aboneliklerindeki dağıtımlarınızla müşterilerinizin giriş bölgeleri arasındaki doğru etkileşimi sağlama.
İkili dağıtım SaaS çözümleri oluşturan ISV'ler aşağıdaki soruları dikkate almalıdır:
- Hem saf SaaS hem de müşteri tarafından dağıtılan çözümler oluşturmak için dikkat edilmesi gereken tüm noktaları gözden geçirdik mi?
- Çözümümüzün hangi bileşenleri Azure aboneliklerimizde barındırılmalıdır ve hangi bileşenler müşteri tarafından dağıtılmalıdır?
- Müşterilerimizin Azure aboneliklerine dağıtılan kaynaklarla güvenli sağlama ve etkileşim sağlamayı nasıl sağlayabiliriz?
Azure giriş bölgesi tasarım ilkeleri ve uygulamaları
Azure giriş bölgesi tasarım ilkeleri Log Analytics, Azure İzleyici ve Azure Güvenlik Duvarı gibi Azure'a özel platform özellikleriyle uyumlu hale getirmenizi önerir. Giriş bölgesi kılavuzu belirli Azure giriş bölgesi uygulama seçeneklerini de sağlar.
ISV olarak kendi giriş bölgesi ortamlarınızı uygulamaya karar vekleyebilirsiniz. Azure kaynaklarını abonelikler arasında dağıtmak için kendi otomasyonunuzu kullanmanız gerekebilir. Veya günlüğe kaydetme, izleme ve diğer platform katmanı hizmetleri için zaten kullandığınız araçları kullanmaya devam etmek isteyebilirsiniz.
Kendi giriş bölgesi ortamlarınızı uygularsanız, başvuru için Azure giriş bölgesi kılavuzlarını ve örnek uygulamaları kullanmanızı ve yaklaşımınızı kanıtlanmış Azure giriş bölgesi tasarımlarıyla uyumlu hale getirmenizi öneririz.
Microsoft Entra kiracıları
Her Azure giriş bölgesi ve yönetim grubu hiyerarşisi tek bir Microsoft Entra kiracısında köklenir. Bu, vermeniz gereken ilk kararın, Azure kaynaklarınızı yönetmek için kimlik kaynağı olarak hangi Microsoft Entra kiracısını kullanacağınız olduğu anlamına gelir. Microsoft Entra Id'deki kimlikler kullanıcılar, gruplar ve hizmet sorumlularıdır.
Bahşiş
Giriş bölgeniz için seçtiğiniz Microsoft Entra kiracısı, uygulama düzeyi kimlik doğrulamanızı etkilemez. Seçtiğiniz kiracıdan bağımsız olarak Azure AD B2C gibi diğer kimlik sağlayıcılarını kullanmaya devam edebilirsiniz.
Azure giriş bölgeleri ve Microsoft Entra kiracıları için kılavuz, tek bir Microsoft Entra kiracısı kullanılmasını kesinlikle önerir ve çoğu durumda bu doğru yaklaşımdır. Ancak SaaS ISV olarak iki kiracı kullanmak için nedeniniz olabilir.
Bazı SaaS ISV'leri için bir ekip şirket kaynaklarını yönetir ve saas çözümünü ayrı bir ekip çalıştırır. Bu ayrım, operasyonel nedenlerle veya mevzuat gereksinimlerine uymak için olabilir. Şirket BT ekibinizin SaaS ile ilgili abonelikleri ve kaynakları yönetmesine izin verilmediğinden Microsoft Entra kiracısının yöneticisi olamazlar. Bu senaryo sizin için geçerliyse, iki ayrı Microsoft Entra kiracısı kullanmayı düşünün: Office 365 gibi kurumsal BT kaynakları için bir kiracı ve SaaS çözümünüzü oluşturan Azure kaynakları için bir kiracı.
Her Microsoft Entra kiracısı kendi etki alanı adına sahip olmalıdır. Kuruluşunuz iki kiracı kullanıyorsa, aşağıdaki diyagramda gösterildiği gibi kurumsal Microsoft Entra kiracınız ve contoso-saas-ops.com SaaS Microsoft Entra kiracınız için gibi contoso.com bir ad seçebilirsiniz.
Uyarı
Birden çok Microsoft Entra kiracısı kullandığınızda yönetim ek yükünüz artar. Privileged Identity Management gibi Microsoft Entra ID P1 veya P2 özelliklerini kullanıyorsanız, her Microsoft Entra kiracısı için tek tek lisans satın alsanız iyi olur. En iyisi, yalnızca durumunuz gerçekten gerektiriyorsa birden çok Microsoft Entra kiracısı kullanmaktır.
Üretim öncesi ve üretim ortamları için ayrı Microsoft Entra kiracıları kullanmaktan kaçının. ve gibi contoso-saas-ops-preprod.comcontoso-saas-ops-prod.com iki kiracı oluşturmak yerine her birinin altında ayrı Azure abonelikleri olması gerekir. Bir Microsoft Entra kiracısı oluşturmanız gerekir. Bu tek kiracı altındaki aboneliklere ve kaynaklara erişimi yönetmek için yönetim gruplarını ve Azure RBAC'yi kullanabilirsiniz.
Birden çok Microsoft Entra kiracısı kullanma hakkında daha fazla bilgi için bkz. Azure giriş bölgeleri ve birden çok Microsoft Entra kiracısı ve Microsoft Entra teknik incelemesi ile Azure ortamlarının güvenliğini sağlama.
Yönetim grupları
Azure giriş bölgesi kavramsal mimarisi belirli bir yönetim grubu hiyerarşisinin kullanılmasını önerir. Ancak, ISV'lerin gereksinimleri diğer kuruluşlardan farklı olabilir. Bu bölümde, ISV kuruluşunuzun giriş bölgesi kavramsal mimarisinin önerdiğinden farklı uygulamaları benimsemeyi seçebileceği bazı yollar açıklanmaktadır.
Üst düzey yönetim grubu
Yönetim grubu hiyerarşiniz Azure tarafından oluşturulan Kiracı kök grubu yönetim grubunun altında iç içe yerleştirilmiştir. Kiracı kök grubunu doğrudan kullanmazsınız.
Platformunu ve paylaşılan hizmetlerini (günlüğe kaydetme, ağ, kimlik ve güvenlik gibi) yöneten merkezi bir kurumsal BT ekibine sahip standart bir kuruluş genellikle Azure tarafından oluşturulan Kiracı kök grubu altında bir üst düzey yönetim grubu oluşturur ve yönetim gruplarının geri kalanını onun altında dağıtır. Bu üst düzey yönetim grubu genellikle kuruluşun kendisinden (Contoso gibi) sonra adlandırılır.
SaaS ISV olarak bir SaaS ürününüz veya birkaç ayrı SaaS ürününüz veya iş kolunuz olabilir. Tüm ürünlerinizde Azure kaynaklarını yönetmek için genel olarak aynı Microsoft Entra kiracısını kullanmanız gerekir (Microsoft Entra kiracıları bölümünde açıklandığı gibi), bazı senaryolarda birden çok yönetim grubu hiyerarşisi dağıtmayı seçebilirsiniz.
Ürünlerinizin birbirinden ne kadar bağımsız olduğunu göz önünde bulundurun ve kendinize şunu sorun:
- Ürünlerimizin tümü DevOps, kimlik, güvenlik, bağlantı ve günlüğe kaydetme için aynı platformları mı kullanıyor?
- Bu paylaşılan hizmetler tek bir merkezi ekip tarafından mı işletiliyor?
Her iki soruya da evet yanıtı verdiyseniz Kiracı kök grubu altında tek bir üst düzey SaaS Ürün yönetim grubu oluşturun.
Bunun yerine hayır yanıtı verdiyseniz ve SaaS ürünlerinizin her biri ayrı platform ekipleri tarafından yönetiliyor ve işletiliyorsa, saas product-01 ve SaaS Product-02 gibi her ürün için ayrı bir üst düzey yönetim grubu oluşturmayı göz önünde bulundurun.
Bahşiş
Tek bir ISV'nin yalnızca birkaç üst düzey yönetim grubuna sahip olması sık karşılaşılan bir durumdur. Genellikle, çeşitli ürünler yönetilme ve çalıştırılma benzerlikleri nedeniyle birlikte birleştirilebilir.
Bu yönetim yaklaşımı, kurumsal ölçekli giriş bölgeleri için test yaklaşımına benzer. Ancak, kiracı kök grubu altında Contoso ve Contoso-Canary oluşturmak yerine, bu yaklaşımda örnek şirket bunun altında ürüne özgü Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 ve Contoso-SaaS-Product-03 üst düzey yönetim gruplarını oluşturur. Bu senaryo aşağıdaki diyagramda gösterilmiştir:
Platform yönetim grubu
Azure giriş bölgesi kaynak kuruluşu hiyerarşisinde Platform yönetim grubu, giriş bölgesi aboneliklerindeki iş yükleri tarafından kullanılan bileşenleri ve paylaşılan hizmetleri barındıran tüm Azure aboneliklerini içerir. Platform ve paylaşılan hizmet aboneliklerine dağıtılan bileşenlere örnek olarak merkezi günlüğe kaydetme altyapısı (Log Analytics çalışma alanları gibi), DevOps, güvenlik, otomasyon araçları, merkezi ağ kaynakları (hub-VNet ve DDos Protection planları gibi) ve bir ISV'nin denetim düzlemi hizmetleri verilebilir.
Platform yönetim grubu, kurumsal müşteriler için rollerin ve ilkelerin kolayca ayrılmasını sağlamak için sıklıkla Kimlik, Yönetim ve Bağlan ivity alt gruplarına ayrılır.
Kuruluşunuzda kimlik, ağ ve yönetim gibi tüm paylaşılan platform bileşenlerini yöneten tek bir ekibiniz olabilir. Öyleyse ve bu yönetimi birden çok ekip arasında ayırmayı planladıysanız, tek bir Platform yönetim grubu kullanmayı göz önünde bulundurun.
Bunun yerine merkezi platformunuzun farklı bölümlerini yöneten ayrı ekipleriniz varsa, Platform yönetim grubu altındaki yönetim grubu hiyerarşisinde başka düzeyler dağıtmanız gerekir. Bu, merkezi platformunuzun her parçası için ayrı ilkeler atamanıza olanak tanır.
Aşağıdaki diyagramda Platform yönetim grubunun iki olası uygulaması gösterilmektedir. A seçeneği, Platform yönetim grubunun üç alt yönetim grubu içerdiği daha kapsamlı bir senaryo gösterir: Yönetim ve DevOps, Kimlik ve Güvenlik ve Bağlan üretkenlik. Her alt yönetim grubu, ilgili kaynaklara sahip bir abonelik içerir. B seçeneği, Platform yönetim grubunun tek bir platform aboneliği içerdiği daha basit bir senaryo gösterir.
Giriş Bölgeleri yönetim grubu
Giriş Bölgeleri yönetim grubu, SaaS çözümünüzün gerçek alt sistemlerini ve iş yüklerini barındıran Azure aboneliklerini içerir.
Bu yönetim grubu bir veya daha fazla alt yönetim grubu içerir. Giriş Bölgeleri altındaki alt yönetim gruplarının her biri, tüm abonelikler için geçerli olması gereken tutarlı ilke ve erişim gereksinimlerine sahip bir iş yükünü veya alt sistem arketipini temsil eder. Birden çok arketip kullanmanın nedenleri şunlardır:
- Uyumluluk: SaaS ürününüzün bir alt sisteminin PCI-DSS uyumlu olması gerekiyorsa Giriş Bölgeleri altında pci DSS arketipli bir alt yönetim grubu oluşturmayı göz önünde bulundurun. PCI-DSS uyumluluğu kapsamındaki kaynakları içeren tüm Azure abonelikleri bu yönetim grubuna yerleştirilmelidir.
- Katmanlar: SaaS çözümünüzün ayrılmış katman müşterileri ve ücretsiz katman müşterileri için ayrı giriş bölgesi arketipleri oluşturmayı göz önünde bulundurun. Alt yönetim gruplarının her biri farklı Azure İlkesi ayarları içerir. Örneğin, ücretsiz katmandaki ilkeler dağıtımları yalnızca belirli sanal makine SKU'larını etkinleştirecek şekilde kısıtlayabilir ve ayrılmış katmandaki ilkeler kaynakların belirli bölgelere dağıtılması gerektirebilir.
Ortama özgü yönetim grupları
SaaS ISV'leri genellikle yazılım geliştirme yaşam döngüsü ortamlarını bir sırayla modelleyerek bulut ortamlarını düzenler. Bu genellikle önce Geliştirme ortamına, ardından Test ortamına, sonra hazırlama ortamına ve son olarak da Üretim ortamına dağıtım gerektirir.
Ortamlar arasındaki yaygın farklardan biri, her abonelik grubuna kimlerin erişebileceği gibi Azure RBAC kurallarıdır. Örneğin DevOps, SaaSOps, geliştirme ve test ekiplerinin tümü farklı ortamlara farklı erişim düzeylerine sahip olabilir.
Önemli
Çoğu Azure müşterisi yüzlerce uygulamaya sahiptir ve her uygulama ekibi için ayrı Azure abonelikleri kullanır. Her uygulamanın kendi geliştirme, test, hazırlama ve üretim yönetim grupları varsa, neredeyse özdeş ilkelere sahip çok sayıda yönetim grubu olacaktır. Çoğu müşteri için Kurumsal Ölçekli Giriş Bölgesi SSS, her ortam için ayrı yönetim gruplarının kullanılmasını önerir. Bunun yerine tek bir yönetim grubu içinde ayrı abonelikler kullanmanızı önerir.
Ancak SaaS ISV'lerinin gereksinimleri diğer Azure müşterilerinin çoğundan farklı olabilir ve bazı durumlarda ortama özgü yönetim gruplarını kullanmak için iyi bir nedeni olabilir.
SaaS ISV'lerinin bazen aynı alt sistemin, uygulamanın veya iş yükünün parçalarını veya bölümlerini temsil eden birden çok aboneliği gruplandırmaları gerekir. Abonelik gruplarına, arketip yönetim grubundan belirgin bir şekilde farklı bir şekilde ilkeler veya rol atamaları uygulamanız gerekebilir. Bu durumda, arketip yönetim grubu altındaki her ortama karşılık gelen çocuk yönetim grupları oluşturmayı göz önünde bulundurun.
Aşağıdaki diyagramlarda iki olası seçenek gösterilmektedir. A seçeneği, her ortam için ayrı aboneliklere sahip olan ancak ortama özgü yönetim grupları olmayan bir senaryo gösterir. B seçeneği, Normal damgalama yönetim grubu altında ortama özgü yönetim grupları içeren bir SaaS ISV senaryosu gösterir. Ortama özgü her yönetim grubu birden çok abonelik içerir. ISV, zaman içinde her ortamdaki Azure kaynaklarını yaygın ilkeler ve rol atamaları kümesiyle artan sayıda abonelik arasında ölçeklendirir.
İki diyagramı görmek için her sekmeyi seçin.
Kullanımdan kaldırılan ve Korumalı Alan yönetim grupları
Azure giriş bölgesi kaynak düzenleme kılavuzu, üst düzey yönetim grubunuzun hemen altında Yetkisini Alınanlar ve Korumalı Alanlar yönetim gruplarının da dahil olduğunu önerir.
Yetkisi alınmış yönetim grubu, devre dışı bırakılan ve sonunda silinecek Olan Azure abonelikleri için bir bekleme yeridir. Artık kullanımda olmayan bir aboneliği, abonelikteki tüm kaynaklar kalıcı olarak silinene kadar izlemek için bu yönetim grubuna taşıyabilirsiniz.
Korumalı Alan yönetim grubu genellikle keşif amacıyla kullanılan ve bunlara gevşek ilke uygulanmış veya hiç ilke uygulanmamış Azure abonelikleri içerir. Örneğin, geliştiricilere geliştirme ve test için kendi aboneliklerini sağlayabilirsiniz. Bu aboneliklere korumalı alan yönetim grubuna yerleştirerek normal ilkeleri ve idareyi uygulamaktan kaçınabilirsiniz. Bu, geliştiricilerin çevikliğini artırır ve Azure ile kolayca denemeler yapmaya olanak tanır.
Önemli
Korumalı Alan yönetim grubundaki aboneliklerin giriş bölgesi aboneliklerine doğrudan bağlantısı olmamalıdır. Korumalı alan aboneliklerini üretim iş yüklerine veya üretim ortamlarını yansıtan üretim dışı ortamlara bağlamaktan kaçının.
Aşağıdaki diyagramda iki olası seçenek gösterilmektedir. A seçeneği Yetkisi Alınmış ve Korumalı Alan yönetim gruplarını içermez, B seçeneği ise içerir.
Örnek ISV giriş bölgeleri
Bu bölüm, SaaS ISV için iki örnek Azure giriş bölgesi yapısı içerir. İki örnek giriş bölgesini karşılaştırmak için her sekmeyi seçin.
Aşağıdaki diyagramda aşağıdaki özelliklere sahip örnek bir SaaS ISV Azure giriş bölgeleri hiyerarşisi gösterilmektedir:
- ISV, tüm platform bileşenlerini birden çok platform yönetim grubuna bölmek yerine tek bir Azure aboneliğinde tutar.
- Yalnızca bir giriş bölgesi yönetim grubu vardır.
- Giriş bölgesi, abonelikleri düzenlemek ve farklı ilkeler ve roller atamak için ortama özgü yönetim gruplarını içerir.
- ISV, kullanımdan kaldırılan ve korumalı alan abonelikleri için yönetim gruplarını içermez.
Sonraki adımlar
- Çok kiracılı bir çözüm oluşturuyorsanız Azure'da çok kiracılı çözümler tasarlama hakkında daha fazla bilgi edinin.
- Azure giriş bölgesi nedir öğrenin.
- Azure giriş bölgesi tasarım alanları hakkında bilgi edinin.