Dağıtım damgaları stili

Dağıtım damga deseninin birden çok iş yükünü veya kiracıyı barındırmak ve çalıştırmak için heterojen bir kaynak grubunu sağlama, yönetme ve izleme işlemi gerekir. Her bir kopyaya bir Damgaveya bazen bir hizmet birimi ya da ölçek birimidenir. Çok kiracılı bir ortamda, her damga veya ölçek birimi önceden tanımlanmış sayıda Kiracı hizmeti sunabilir. Çözümü neredeyse doğrusal olarak ölçeklendirmek ve artan sayıda kiracıyı karşılamak için birden çok damga dağıtılabilir. Bu yaklaşım, çözümünüzün ölçeklenebilirliğini iyileştirebilirler, birden çok bölgeye örnek dağıtmanıza ve müşteri verilerinizi ayırmanızı sağlar.

Bağlam ve sorun

Bulutta bir uygulamayı barındırırken, bazı önemli noktalar vardır. Dikkat etmeniz gereken bir önemli şey, uygulamanızın performansı ve güvenilirliği olduğunu göz önünde bulundursun. Çözümünüzün tek bir örneğini barındırdıysanız aşağıdaki sınırlamalara tabi olabilirsiniz:

• Ölçek sınırları. Uygulamanızın tek bir örneğini dağıtmak doğal ölçekleme sınırlarına neden olabilirler. Örneğin, gelen bağlantı sayısı, ana bilgisayar adları, TCP yuvaları veya diğer kaynaklar için sınırlara sahip hizmetleri kullanabilirsiniz.
• Doğrusal olmayan ölçekleme veya maliyet. Çözümünüzün bazı bileşenleri, istek sayısı veya veri miktarı ile doğrusal şekilde ölçeklendirmeyebilir. Bunun yerine, bir eşik karşılandıktan sonra performansta ani bir düşüş olabilir veya maliyette artış vardır. Örneğin, bir veritabanı kullanabilir ve daha fazla kapasite ekleme (ölçeği artırma) marjinal maliyetinin, bir ölçüde daha fazla hale geldiğini ve ölçeklendirmenin daha uygun maliyetli bir strateji olduğunu keşfedebilirsiniz. Benzer şekilde, çok sayıda özel etki alanı dağıtıldığında Azure ön kapısının etki alanı başına fiyatları daha yüksektir ve özel etki alanlarını birden fazla ön kapı örneğine yaymak daha iyi olabilir.
• Müşterilerin ayrımı. Belirli müşterilerin verilerinin diğer müşterilerin verilerinin yalıtılmasını saklamanız gerekebilir. Benzer şekilde, diğer müşterilere daha fazla sistem kaynağı gerektiren bazı müşterileriniz olabilir ve bunları farklı altyapı kümelerinde gruplamayı göz önünde bulundurun.
• Tek ve çok kiracılı örnekleri işleme. Çözümünüzün kendi bağımsız örneklerine ihtiyaç duyan bazı büyük müşterileriniz olabilir. Ayrıca, çok kiracılı bir dağıtımı paylaşabilen daha küçük bir müşteri havuzunuz olabilir.
• Karmaşık dağıtım gereksinimleri. Güncelleştirmeleri denetimli bir biçimde dağıtmanız ve farklı zamanlarda müşteri tabanlarınızın farklı alt kümelerine dağıtmanız gerekebilir.
• Güncelleştirme sıklığı. Sisteminizde sık güncelleştirmelere sahip olan bazı müşterileriniz olabilir. diğer bir deyişle, risk karşıtı olabilir ve sistem isteklerine hizmet vermek için sık sık güncelleştirmeler yapmak isteyebilirsiniz. Bu müşterilerin yalıtılmış ortamlara dağıtılması mantıklı olabilir.
• Coğrafi veya geopolitik kısıtlamalar. Düşük gecikme süresini ve veri egemenlik gereksinimleriyle uyum sağlamak için, bazı müşterilerinizin belirli bölgelere dağıtımını yapabilirsiniz.

Çözüm

Bu sorunlardan kaçınmak için, kaynakları Ölçek birimlerinde gruplandırmayı ve damgalar'ın birden çok kopyasını sağlamayı göz önünde bulundurun. Her ölçek birimi , Kiracılarınızın bir alt kümesini barındırır ve sunar. Damgalar birbirinden bağımsız olarak çalışır ve bağımsız olarak dağıtılabilir ve güncelleştirilir. Tek bir coğrafi bölge tek bir damga içerebilir veya bölge içinde yatay ölçeklendirmeyi sağlamak için birden çok damga içerebilir. Damgalar, müşterilerinizin bir alt kümesini içerir.

Dağıtım damgaları, çözümünüzün hizmet olarak altyapı (IaaS) veya hizmet olarak platform (PaaS) bileşenleri mi yoksa her ikisinin karışımı mi kullanacağını uygulayabilir. Genellikle IaaS iş yükleri ölçeklendirmek için daha fazla müdahale gerektirir. bu nedenle, ölçeklendirme için izin vermek üzere IaaS ağır iş yükleri için model yararlı olabilir.

Damgalar, dağıtım halkalarınıuygulamak için kullanılabilir. Farklı müşteriler hizmet güncelleştirmelerini farklı sıklıklarca almak istiyorlarsa, farklı damgalar üzerinde gruplandırılabilir ve her damga farklı bir noktada dağıtılan güncelleştirmeler elde edebilir.

Damgalar birbirinden bağımsız olarak çalıştırıldığından, veriler örtülü olarakoluşturulur. Ayrıca, tek bir damga, iç Damgadaki ölçeklenebilirlik ve esneklik için dahili olarak daha fazla parça kullanılmasına yol açabilir.

dağıtım damga düzeniyle App Service, Azure Stackve azure Depolamadahil birçok Azure hizmeti tarafından dahili olarak kullanılır.

Dağıtım damgaları, ve coğrafiolarak birbirinden farklıdır. Bir dağıtım damgası mimarisinde, sisteminizin birden çok bağımsız örneği dağıtılır ve müşterilerinizin ve kullanıcılarınızın bir alt kümesini içerir. Coğrafi olarak, tüm örnekler tüm kullanıcılardan istekleri sunabilir, ancak bu mimaride tasarlamak ve derlemek genellikle daha karmaşıktır. Ayrıca, bir çözüm içinde iki deseni karışmaya de göz önünde bulundurmanız gerekir. Aşağıda açıklanan trafik yönlendirme yaklaşımı , bu tür bir karma senaryoya örnektir.

Dağıtım

aynı bileşenlerin özdeş kopyalarını dağıtmaya dahil olan karmaşıklık nedeniyle, bu düzenin uygulanması sırasında başarılı olduğundan emin olmak için iyi DevOps yöntemler kritik öneme sahiptir. Altyapınızı Bıcep, JSON Azure Resource Manager şablonları (ARM şablonları), terkformve betikler gibi kod olarak açıklayan düşünün. Bu yaklaşımda, her damga dağıtımının öngörülebilir ve yinelenebilir olmasını sağlayabilirsiniz. Ayrıca, damgalar arasında yapılandırmada yanlışlıkla uyuşmazlıklar gibi insan hatalarının olasılığını da azaltır.

Güncelleştirmeleri otomatik olarak tüm damgalara otomatik olarak dağıtabilirsiniz. Bu durumda, altyapının ve uygulamalarınızın dağıtımını koordine etmek için Bıcep veya Kaynak Yöneticisi şablonları gibi teknolojileri düşünebilirsiniz. Alternatif olarak, önce bazı damgalar ve daha sonra giderek diğerleri için güncelleştirmeleri kademeli olarak kullanıma alabilir. her damga için dağıtımları düzenlemek üzere Azure Pipelines veya GitHub eylemleri gibi bir release management aracı kullanmayı düşünün. Daha fazla bilgi için bkz.

• Bicep 'yi Azure Pipelines ile tümleştirin
• JSON ARM şablonlarını Azure Pipelines ile tümleştirme

Dağıtımlarınız için Azure aboneliklerinin ve kaynak gruplarının topolojisini dikkatle değerlendirin:

• Genellikle bir abonelik tek bir çözüm için tüm kaynakları içerir, bu nedenle genel olarak tüm damgalar için tek bir abonelik kullanmayı düşünün. Ancak, bazı Azure hizmetleri abonelik genelinde kotalaroluşturur, bu nedenle yüksek ölçüde genişleme için izin vermek üzere bu kalıbı kullanıyorsanız, damgaları farklı abonelikler arasında dağıtmaya dikkat etmeniz gerekebilir.
• Kaynak grupları genellikle aynı yaşam döngüsüne sahip bileşenleri dağıtmak için kullanılır. Tüm Damgalarınız için aynı anda güncelleştirme dağıtmayı planlıyorsanız, tüm damgalarınızın tüm bileşenlerini içeren tek bir kaynak grubu kullanmayı düşünün ve her bir damgaya ait bileşenleri tanımlamak için kaynak adlandırma kurallarını ve etiketlerini kullanın. Alternatif olarak, her bir damgada güncelleştirmeleri bağımsız olarak dağıtmayı planlıyorsanız, her damgayı kendi kaynak grubuna dağıtmayı göz önünde bulundurun.

Kapasite planlaması

Belirli bir damgasının barındırabilecek yaklaşık yükü öğrenmek için yük ve performans testini kullanın. Yük ölçümleri, tek bir damgacının barındırabilecek müşterilerin/kiracıların sayısına veya damga içindeki bileşenlerin bulunduğu hizmetlerden alınan ölçümlere dayalı olabilir. Belirli bir damga kapasitesine yaklaştığı zaman ölçmeye yönelik yeterli izleme olduğundan ve isteğe yanıt vermek için yeni damgaları hızlı bir şekilde dağıtma olanınızdan emin olun.

Trafik yönlendirme

Dağıtım damga şekli, her damga bağımsız olarak kullanılıyorsa iyi bir şekilde gerçekleştirilir. Örneğin, contoso aynı API uygulamasını birden çok damga genelinde dağıttığında, trafiği ilgili damgasına yönlendirmek için DNS kullanmayı düşünebilirler:

• unit1.aus.myapi.contoso.com trafiği unit1 bir Avustralya bölgesi içindeki damgaya yönlendirir.
• unit2.aus.myapi.contoso.com trafiği unit2 bir Avustralya bölgesi içindeki damgaya yönlendirir.
• unit1.eu.myapi.contoso.com trafiği unit1 Avrupa bölgesi içindeki damgaya yönlendirir.

Daha sonra, istemciler doğru damgaya bağlanmaktan sorumludur.

Tüm trafik için tek bir giriş noktası gerekliyse, belirli bir istek, müşteri veya kiracı için damgayı çözümlemek üzere bir trafik yönlendirme hizmeti kullanılabilir. Trafik yönlendirme hizmeti, istemciyi damga için ilgili URL 'ye yönlendirir (örneğin, bir HTTP 302 yanıt durum kodu kullanarak) ya da ters bir ara sunucu olarak davranabilir ve istemci farkında olmadan trafiği ilgili damgasına iletebilir.

Merkezi bir trafik yönlendirme hizmeti, özellikle bir çözüm birden çok bölgede çalıştırıldığında tasarlamak üzere karmaşık bir bileşen olabilir. Trafik yönlendirme hizmetini birden çok bölgeye (büyük olasılıkla, damgalar 'ın dağıtıldığı her bölge de dahil olmak üzere) dağıtıp, ardından veri deposunun (kiracıları damgalar ile eşleme) eşitlendiğinden emin olmanız önerilir. Trafik yönlendirme bileşeni, Geode desenininbir örneği tarafından kendi kendine gelebilir.

Örneğin, Azure API Management trafik yönlendirme hizmeti rolünde çalışacak şekilde dağıtılabilir. kiracılar ve damgalar arasında eşlemeyi depolayan bir Cosmos DB koleksiyonundaki verileri arayarak bir istek için uygun damgası tespit edebilir. API Management, arka uç URL 'sini ilgili damgasının API hizmetine dinamik olarak ayarlayabilir .

İsteklerin coğrafi dağıtımını ve trafik yönlendirme hizmeti 'nin coğrafi yedekliliği etkinleştirmek için API Management birden çok bölgeye dağıtılabilirveya Azure ön kapısının trafiği en yakın örneğe yönlendirmek için kullanılabilir. Ön kapı, bir arka uç havuzuylayapılandırılabilir ve isteklerin en yakın kullanılabilir API Management örneğine yönlendirilmesine olanak tanır. uygulamanız HTTP/S aracılığıyla gösterilmediğinden, bölgesel Azure yük dengeleyicilerine gelen çağrıları dağıtmak için bir çapraz bölge Azure Load Balancer kullanabilirsiniz. Azure Cosmos DB genel dağıtım özelliği , eşleme bilgilerinin her bölgede güncelleştirilmesini sağlamak için kullanılabilir.

Çözümünüzde bir trafik yönlendirme hizmeti varsa, bir ağ geçidi olarak görev yapıp gerçekleştirmediğini göz önünde bulundurun ve bu nedenle belirteç doğrulama, azaltma ve yetkilendirme gibi hizmetler için ağ geçidi boşaltma işlemi gerçekleştirin.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacağınıza karar verirken aşağıdaki noktaları dikkate almalısınız:

• Dağıtım işlemi. Birden çok damga dağıtıldığında, otomatik ve tamamen yinelenebilir dağıtım işlemlerinin olması önemle önerilir. Damgası bildirimli olarak tanımlamak için Bıcep, JSON ARM şablonlarınıveya terkform modüllerini kullanmayı düşünün.
• Çapraz damga işlemleri. Çözümünüz birden çok damgada bağımsız olarak dağıtıldığında, "her bir damgamız genelinde kaç müşteri yaptığımız?" gibi sorular yanıt vermek daha karmaşık olabilir. Sorguların her damgaya karşı yürütülmesi ve toplanacak sonuçlar olması gerekebilir. Alternatif olarak, birleştirilmiş raporlama için tüm damgaların verileri merkezi bir veri ambarına yayımlamasını göz önünde bulundurun.
• Genişleme ilkelerini belirleme. Damgalar, damgaya dağıtılabilecek kiracı sayısı gibi bir ara sunucu ölçümü kullanılarak tanımlanmış sınırlı kapasiteye sahiptir. Her damga için kullanılabilir kapasiteyi ve kullanılan kapasiteyi izlemek ve yeni kiracıların bunlara yönlendirilmesine izin vermek için ek damgaları önceden dağıtmak önemlidir.
• Maliyet. Dağıtım damga düzeniyle, büyük olasılıkla çözümünüzü çalıştırma maliyetinde önemli bir artış içeren altyapı bileşeninizin birden çok kopyasının dağıtılması gerekir.
• Damgalar arasında taşıma. Her damga bağımsız olarak dağıtılan ve işletilen için, kiracıların damgalar arasında taşınması zor olabilir. Uygulamanız belirli bir müşteri hakkındaki bilgileri farklı bir damgaya iletmek ve sonra kiracının bilgilerini özgün damgadan kaldırmak için özel mantık gerektirir. Bu işlem, damgalar arasında iletişim için bir arka düzlem gerektirebilir ve genel çözümün karmaşıklığını artırır.
• Trafik yönlendirme. Yukarıda açıklandığı gibi, belirli bir istek için doğru damgaya yönlendirme trafiği, kiracıları damgalara çözümlemek için ek bir bileşen gerektirebilir. Bu bileşenin sırasıyla yüksek oranda kullanılabilir olması gerekebilir.
• Paylaşılan bileşenler. Damgalar arasında paylaşılabilen bazı bileşenleriniz olabilir. örneğin, tüm kiracılara yönelik paylaşılan bir tek sayfalı uygulamanız varsa, bunu tek bir bölgeye dağıtıp Azure CDN kullanarak genel olarak çoğaltabilirsiniz.

Bu düzenin kullanılacağı durumlar

Bu model, şunları yaptığınızda yararlı olur:

• Ölçeklenebilirlik için doğal sınırlamalar. Örneğin, bazı bileşenler belirli sayıda müşteriyi veya isteği aşacak şekilde ölçeklendiremez veya ölçeklendirmemelidir, damgalar kullanarak ölçeği azaltmayı göz önünde bulundurun.
• Belirli kiracıların başkalarından ayrılması için bir gereksinim. Güvenlik sorunları nedeniyle diğer müşterilerle çok kiracılı bir damgaya dağıtılabilecek müşterileriniz varsa, kendi yalıtılmış damgalarına dağıtılabilir.
• Aynı anda çözümünüzün farklı sürümlerinde bazı kiracılar olması gerekir.
• Her kiracının verilerinin ve trafiğinin belirli bir bölgeye yönlendirilmesi gereken çok bölgeli uygulamalar.
• Kesintiler sırasında dayanıklılık elde etmek ister. Damgalar birbirinden bağımsız olduğundan, bir kesinti tek bir damgayı etkiliyorsa, diğer damgalara dağıtılan kiracılar etkilenmemelidir. Bu yalıtım, bir olayın veya kesintiden ' bir kesinti ' yarıçapını bulundurmasına yardımcı olur.

Bu model için uygun değil:

• Yüksek derecede ölçeklendirilmesi gerekmeyen basit çözümler.
• Uygulama katmanının boyutunu arttırarak veya veritabanları ve depolama katmanı için ayrılan kapasiteyi artırarak gibi tek bir örnek içinde kolayca ölçeklendirilebilir sistemler.
• Dağıtılan tüm örneklerde verilerin çoğaltılması gereken çözümler. Bu senaryo için Geode modelini göz önünde bulundurun.
• Yalnızca bazı bileşenlerin ölçeklenmesini gerektiren çözümler, ancak diğerleri değil. Örneğin, çözümünüzün tüm çözüm bileşenlerinin yeni bir kopyasını dağıtmak yerine , veri deposunun parçalara ölçeklendirilmesine göre ölçeklenemeyeceğini göz önünde bulundurun.
• Yalnızca, ön uç JavaScript uygulaması gibi statik içerikten oluşan çözümler. Bu tür içeriği bir depolama hesabında depolamayı ve Azure CDNkullanmayı göz önünde bulundurun.

Destekleyici teknolojiler

• Kod olarak altyapı. Örneğin, Bıcep, Kaynak Yöneticisi şablonları, Azure CLı, Terrampaform, PowerShell, Bash.
• Trafiği belirli bir damgaya veya trafik yönlendirme hizmetine yönlendirebilen Azure ön kapısıdır.

Örnek

aşağıdaki örnek, her bir damgada bir app service ve bir SQL Veritabanı basit bir paas çözümünün birden çok damgasını dağıtır. Damgaları, şablonda dağıtılan hizmetleri destekleyen herhangi bir bölgede yapılandırılabilirken, çizim amacıyla bu şablon Batı ABD 2 bölgesinde iki damga ve Batı Avrupa bölgesinde daha fazla damga dağıtır. Bir damga içinde App Service kendi ortak DNS ana bilgisayar adını alır ve diğer tüm damgalardan bağımsız olarak bağlantı alabilir.

Çözümü dağıtmak için aşağıdaki bağlantıya tıklayın.

Örnek trafik yönlendirme yaklaşımı

Aşağıdaki örnek, bir kuramsal API uygulaması için bir dağıtım damgaları kümesiyle kullanılabilecek bir trafik yönlendirme çözümünün uygulamasını dağıtır. Gelen isteklerin coğrafi dağıtımına izin vermek için ön kapı, tüketim katmanında birden çok API Management örneği ile dağıtılır. her bir API Management örneği, istek URL 'sinden kiracı kimliğini okur ve sonra coğrafi olarak dağıtılan bir Cosmos DB veri deposundan gelen istek için ilgili damgayı arar. İstek daha sonra ilgili arka uç damgasına iletilir.

Çözümü dağıtmak için aşağıdaki bağlantıya tıklayın.

İlgili yönergeler

• Parçalama, veri katmanınızı ölçeklendirmeye yönelik başka bir, daha basit ve yaklaşım olarak kullanılabilir. Damgalar, verilerini örtülü olarak parçalar, ancak parçalama bir dağıtım damgası gerektirmez. Daha fazla bilgi için bkz. Parçalama düzeni.
• Trafik yönlendirme hizmeti dağıtılmışsa, bu bileşenin en iyi kullanımını sağlamak için ağ geçidi yönlendirme ve ağ geçidi boşaltma desenleri birlikte kullanılabilir.