Azure Kubernetes Service (AKS) ve MySQL Esnek Sunucu iş yüklerini kullanılabilirlik alanı desteğine geçirme

Bu kılavuzda, tüm bağımlı hizmetler genelinde kullanılabilirlik alanı desteğini tamamlamak için Azure Kubernetes Service ve MySQL Esnek Sunucu iş yükünü geçirme işlemi açıklanmaktadır. Tüm iş yükü bağımlılıklarının tam listesi için bkz . İş yükü hizmeti bağımlılıkları.

AKS kümenizin veya MySQL Esnek Sunucunuzun oluşturulması sırasında bu iş yükü için kullanılabilirlik alanı desteği etkinleştirilmelidir. Mevcut aks kümesi ve MySQL Esnek Sunucusu için kullanılabilirlik alanı desteği istiyorsanız, bu kaynakları yeniden dağıtmanız gerekir.

Bu geçiş kılavuzunda temel olarak Azure'da aşağıdaki mimariyi çalıştırmaya yönelik altyapı ve kullanılabilirlik konuları ele alınmaktadır:

İş yükü hizmeti bağımlılıkları

Kullanılabilirlik alanları için tam iş yükü desteği sağlamak için iş yükündeki her hizmet bağımlılığının kullanılabilirlik alanlarını desteklemesi gerekir.

Kullanılabilirlik alanı tarafından desteklenen hizmetlerin iki yaklaşım türü vardır: bölgesel veya alanlar arası yedekli. Çoğu hizmet birini veya diğerini destekler. Ancak bazı durumlarda, söz konusu hizmet için bölgesel veya alanlar arası yedekli bir kaynak seçme seçenekleri vardır. Hangi hizmetlerin bölgesel ve alanlar arası yedekli kaynakları desteklediğini aşağıdaki önerilerde belirteceğiz. Ayrıca hangi hizmetlerin küresel ve bölgesel olduğunu da belirtiyoruz.

AKS ve MySQL iş yükü mimarisi aşağıdaki bileşen bağımlılıklarından oluşur:

Azure Kubernetes Service (AKS)

• Bölgesel : Oluşturma sırasında düğüm havuzlarının dağıtılacağı bölgeleri önceden seçtiğinizde sistem düğümü havuzu ve kullanıcı düğümü havuzları bölgeseldir. Daha iyi dayanıklılık için üç bölgeyi de önceden seçmenizi öneririz. Kullanılabilirlik alanlarını destekleyen daha fazla kullanıcı düğümü havuzu mevcut bir AKS kümesine eklenebilir ve parametresi için zones bir değer sağlanır.

• Alanlar arası yedekli: Etcd, API sunucusu, Zamanlayıcı ve Denetleyici Yöneticisi gibi Kubernetes denetim düzlemi bileşenleri bölgeler arasında otomatik olarak çoğaltılır veya dağıtılır.

  Dekont

  AKS kümesi denetim düzlemi bileşenlerinin alanlar arası yedekliliğini etkinleştirmek için, AKS kümesi oluştururken varsayılan sistem düğümü havuzunuzu bölgelerle tanımlamanız gerekir. Mevcut bölgesel olmayan AKS kümesine daha fazla bölgesel düğüm havuzu eklemek AKS kümesini alanlar arası yedekli hale getirmez, çünkü bu eylem denetim düzlemi bileşenlerini olgudan sonra bölgeler arasında dağıtmaz.

MySQL için Azure Veritabanı Esnek Sunucu

• Bölgesel: Bölgesel kullanılabilirlik modu, bir hazır bekleyen sunucunun birincil sunucuyla aynı bölgede her zaman kullanılabilir olduğu anlamına gelir. Bu seçenek yük devretme süresini ve ağ gecikme süresini kısaltsa da, hem birincil hem de bekleme sunucularını etkileyen tek bir bölge kesintisi nedeniyle daha az dayanıklıdır.

• Alanlar arası yedekli: Alanlar arası yedekli kullanılabilirlik modu, bir hazır bekleyen sunucunun birincil sunucuyla aynı bölgedeki başka bir bölgede her zaman kullanılabilir olduğu anlamına gelir. Birincil ve bekleme sunucuları için alanlar arası yedeklilik için iki bölge etkinleştirilir. Daha iyi dayanıklılık için bu yapılandırmayı öneririz.

Azure Standart Load Balancer veya Azure Uygulaması lication Gateway

Standart Load Balancer

Standart Load Balancer kaynaklarıyla ilgili önemli noktaları anlamak için bkz. Load Balancer ve Kullanılabilirlik Alanları.

• Alanlar arası yedekli: Ön uç IP'nizi mevcut Load Balancer'ınızla yapılandırmanın önerilen yolu alanlar arası yedeklilik seçmektir. Alanlar arası yedekli ön uç, birden çok bölgeye dağıtılan AKS kümesi arka uç havuzuna karşılık gelir.

• Bölgesel: Düğüm havuzlarınızı bölge 1 ve 2 gibi belirli bölgelere sabitliyorsanız, mevcut Load Balancer'da Ön Uç IP'niz için bölge 1 ve 2'yi önceden seçebilirsiniz. Düğüm havuzlarınızı belirli bölgelere sabitlemek istemenizin nedeni, M serisi gibi özelleştirilmiş VM SKU serisinin kullanılabilirliği olabilir.

Azure Application Gateway

AKS kümenizle Application Gateway Giriş Denetleyicisi eklentisinin kullanılması yalnızca Application Gateway v2 SKU'larında (Standart ve WAF) desteklenir. Azure Uygulaması Lication Gateway ile ilgili diğer konuları anlamak için bkz. Application Gateway v2 ve WAF v2'yi ölçeklendirme.

Bölgesel: Kullanılabilirlik alanlarının avantajlarını kullanmak için Application Gateway kaynağının bölge 1, 2 ve 3 gibi birden çok bölgede oluşturulmasını öneririz. En iyi bölge içi dayanıklılık stratejisi için üç bölgeyi de seçin. Ancak, arka uç düğüm havuzlarınıza karşılık gelecek şekilde, App Gateway kaynağınızı oluştururken bölge 1 ve 2'yi önceden seçerek düğüm havuzlarınızı belirli bölgelere sabitleyebilirsiniz. Düğüm havuzlarınızı belirli bölgelere sabitlemek istemenizin nedeni gibi M-seriesözelleştirilmiş VM SKU serisinin kullanılabilirliği olabilir.

Bölgede Yedekli Depolama (ZRS)

• Alanlar arası yedekli kaynaklar olduğundan AKS kümenizin yönetilen ZRS diskleriyle yapılandırılması önerilir. Birimler tüm bölgelerde zamanlanabilir.

• Kubernetes, 1.12 sürümünden bu yana Azure kullanılabilirlik alanlarının farkındadır. Çok bölgeli AKS PersistentVolumeClaim kümesinde Azure Yönetilen Disk'e başvuran bir nesne dağıtabilirsiniz. Kubernetes, bu PVC'yi doğru kullanılabilirlik alanında talep eden tüm podları zamanlamayı üstlenir.

• SQL için Azure Veritabanı için, verilerin ve günlük dosyalarının alanlar arası yedekli depolamada (ZRS) barındırıldığını öneririz. Bu dosyalar, ZRS ile kullanılabilen depolama düzeyinde çoğaltma yoluyla hazır bekleyen sunucuya çoğaltılır.

Azure Güvenlik Duvarı

Bölgesel: Kullanılabilirlik alanlarının avantajlarını kullanmak için, Azure Güvenlik Duvarı kaynağının bölge 1, 2 ve 3 gibi birden çok bölgede oluşturulmasını öneririz. En iyi bölge içi dayanıklılık stratejisi için üç bölgeyi de seçmenizi öneririz.

Azure Bastion

Bölgesel: Azure Bastion, sanal ağlar veya eşlenmiş sanal ağlar içinde dağıtılır ve bir Azure bölgesiyle ilişkilendirilir. Daha fazla bilgi için se Bastion SSS.

Azure Container Registry (ACR)

Alanlar arası yedekli: Premium hizmet katmanında alanlar arası yedekli bir kayıt defteri oluşturmanızı öneririz. Ayrıca, çoğaltmanın özelliğini ayarlayarak zoneRedundancy alanlar arası yedekli bir kayıt defteri çoğaltması da oluşturabilirsiniz. ACR'niz için bölge yedekliliğini etkinleştirmeyi öğrenmek için bkz . Dayanıklılık ve yüksek kullanılabilirlik için Azure Container Registry'de bölge yedekliliğini etkinleştirme.

Redis için Azure Önbelleği

Alanlar arası yedekli: Redis için Azure Cache, Premium ve Kurumsal katmanlarında alanlar arası yedekli yapılandırmaları destekler. Alanlar arası yedekli önbellek, düğümlerini aynı bölgedeki farklı kullanılabilirlik alanlarına yerleştirir.

Microsoft Entra Kimliği

Genel: Microsoft Entra ID, birden çok iç yedeklilik düzeyine ve otomatik kurtarılabilirliğe sahip genel bir hizmettir. Microsoft Entra ID, mevcut olduğunda kullanılabilirlik alanları sağlayan dünyanın dört bir yanındaki 30'un üzerinde veri merkezine dağıtılır. Daha fazla bölge dağıtıldıkçe bu sayı hızla artmaktadır.

Azure Key Vault

Bölgesel: Azure Key Vault bir bölgeye dağıtılır. Anahtarlarınızın ve gizli dizilerinizin yüksek dayanıklılığını korumak için anahtar kasanızın içeriği bölge içinde ve aynı coğrafyadaki ikincil bir bölgeye çoğaltılır.

Alanlar arası yedekli: Kullanılabilirlik alanları olan ve bölge çifti olmayan Azure bölgeleri için Key Vault, anahtar kasanızın içeriğini tek bir konum/bölge içinde üç kez çoğaltmak için alanlar arası yedekli depolama (ZRS) kullanır.

İş yüküyle ilgili dikkat edilmesi gerekenler

Azure Kubernetes Service (AKS)

• Podlar, hangi düğüme veya podun düğüme indiği kullanılabilirlik alanına bakılmaksızın diğer podlarla iletişim kurabilir. Podlar farklı kullanılabilirlik alanlarında bulunuyorsa uygulamanız daha uzun yanıt süresiyle karşılaşabilir. Podlar arasındaki ek gidiş dönüş gecikme sürelerinin çoğu uygulama için kabul edilebilir bir aralıkta olması beklense de, özellikle podlar arasındaki gevedik bir iletişim düzeni için düşük gecikme süresi gerektiren uygulama senaryoları vardır.

• Uygulamanızın kullanılabilirlik alanlarında iyi çalıştığından emin olmak için uygulamanızı test etmenizi öneririz.

• Düşük gecikme süresi gibi performans nedenleriyle podlar aynı kullanılabilirlik alanı içindeki aynı veri merkezinde birlikte bulunabilir. Aynı kullanılabilirlik alanı içinde aynı veri merkezindeki podları birlikte bulmak için benzersiz bir bölge ve yakınlık yerleştirme grubuna sahip kullanıcı düğümü havuzları oluşturabilirsiniz. Yeni bir aracı düğümü havuzu oluşturup PPG'yi belirterek mevcut AKS kümesine yakınlık yerleştirme grubu (PPG) ekleyebilirsiniz. Podların AKS kümenizde kullanılabilirlik alanları, düğümler ve bölgeler arasında nasıl yayıldığını denetlemek için Pod Topolojisi Yayma Kısıtlamalarını kullanın.

• Düşük gecikme süreli iletişim gerektiren podlar aynı kullanılabilirlik alanında birlikte bulunduktan sonra podlar arasındaki iletişim doğrudan değildir. Bunun yerine, pod iletişimleri AKS kümenizdeki mantıksal pod kümesini tanımlayan bir hizmet aracılığıyla kanallandırılır. Podlar AKS ile iletişim kuracak şekilde yapılandırılabilir ve hizmetle iletişim, hizmetin üyesi olan tüm podlara otomatik olarak yük dengelemesi yapılır.

• Kullanılabilirlik alanlarından yararlanmak için düğüm havuzları, bölgesel kaynaklar olan temel VM'leri içerir. Farklı işlem veya depolama taleplerine sahip uygulamaları desteklemek için, kullanıcı düğümü havuzunu oluştururken belirli VM boyutlarına sahip kullanıcı düğümü havuzları oluşturabilirsiniz.

  Örneğin, uygulamanızdaki mikro hizmetler yüksek aktarım hızı, düşük gecikme süresi ve yüksek vCPU sayıları ve büyük miktarda bellek sağlayan bellek için iyileştirilmiş VM boyutları gerektirdiğinden kullanıcı düğümleriniz için öğesini M-series kullanmaya Standard_M32ms karar vekleyebilirsiniz. Dağıtım bölgesine bağlı olarak, Azure portalında VM boyutunu seçtiğinizde, bu VM boyutunun yalnızca 1. ve 2. bölgede desteklendiğini görebilirsiniz. Bu dayanıklılık yapılandırmasını yüksek performans için bir denge olarak kabul edebilirsiniz.

• Düğüm havuzunu oluşturduktan sonra vm boyutunu değiştiremezsiniz. Düğüm havuzu sınırlamaları hakkında daha fazla bilgi için bkz . Sınırlamalar.

MySQL için Azure Veritabanı Esnek Sunucu

Düğüm havuzlarınızı bölge 1 ve 2 gibi belirli bölgelere dağıtmanın etkisi, AKS kümenizin tüm hizmet bağımlılıklarının bölge 1 ve 2'yi de desteklemesi gerektiğidir. Bu iş yükü mimarisinde AKS kümenizin bölge dayanıklılığına sahip MySQL için Azure Veritabanı Esnek Sunuculara hizmet bağımlılığı vardır. Birincil sunucunuz için bölge 1 ve hazır bekleyen sunucunuzun AKS kullanıcı düğümü havuzlarınızla birlikte bulunması için bölge 2'yi seçebilirsiniz.

Redis için Azure Önbelleği

• Redis için Azure Cache, alanlar arası yedekli önbellekteki düğümleri seçtiğiniz kullanılabilirlik alanları üzerinde hepsini bir kez deneme şeklinde dağıtır.

• Mevcut premium önbelleği bölge yedekliliğini kullanacak şekilde güncelleştiremezsiniz. Alanlar arası yedekliliği kullanmak için Redis için Azure Cache yeniden oluşturmanız gerekir.

• En iyi dayanıklılığı elde etmek için, çoğaltmaları üç kullanılabilirlik alanına dağıtabilmeniz için üç veya daha fazla çoğaltmayla Redis için Azure Cache oluşturmanızı öneririz.

Olağanüstü durum kurtarmayla konusunda dikkat edilmesi gerekenler

Kullanılabilirlik alanları , dağıtımınızın birincil bölgesi içinde iş yükünüzün yüksek kullanılabilirliğini elde etmek için daha iyi dayanıklılık için kullanılır.

Olağanüstü Durum Kurtarma , iş sürekliliği planınızda tanımlanan kurtarma işlemlerinden ve uygulamalarından oluşur. İş sürekliliği planınız hem iş yükünüzün kesintiye neden olan bir olay sırasında nasıl kurtarılır hem de olaydan sonra nasıl tamamen kurtarılır? Dağıtımınızı alternatif bir bölgeye genişletmeyi göz önünde bulundurun.

Uygulama katmanınız için lütfen bu makalede AKS için iş sürekliliği ve olağanüstü durum kurtarma konularını gözden geçirin.

• Alternatif bölgelerde birden çok AKS kümesi çalıştırmayı göz önünde bulundurun. Alternatif bölge, ikincil bir eşleştirilmiş bölge kullanabilir. Alternatif olarak, birincil bölgeniz için bölge eşleştirmesi olmadığında, kullanılabilir hizmetler, kapasite, coğrafi yakınlık ve veri hakimiyeti konularına göre alternatif bir bölge seçebilirsiniz. Lütfen Azure bölgeleri karar kılavuzunu gözden geçirin. Ayrıca dağıtım damgası desenini de gözden geçirin.

• AKS kümeleriniz için etkin-etkin, etkin-bekleme, etkin-pasif yapılandırma seçeneğiniz vardır.

• Veritabanı katmanınız için olağanüstü durum kurtarma özellikleri coğrafi geri yükleme başlatma ve okuma amaçlı çoğaltmaları farklı bir bölgede dağıtma özelliğine sahip coğrafi olarak yedekli yedeklemeler içerir.

• Kesinti sırasında kurtarma başlatıp başlatmayacağınız konusunda karar vermeniz gerekir. Kurtarma işlemlerini başlatmanız için kesintinin iş yükünüzün kurtarma süresi hedefinden (RTO) daha uzun sürmesi gerekir. Aksi takdirde, Azure Hizmet Durumu Panosu'nda hizmet durumunu denetleyerek hizmet kurtarmayı beklersiniz. Azure portalının Hizmet Durumu dikey penceresinde aboneliğinizle ilişkili tüm bildirimleri görüntüleyebilirsiniz.

• MySQL için Azure Veritabanı coğrafi geri yükleme özelliğiyle kurtarma başlattığınızda, başka bir bölgeden çoğaltılan yedekleme verileri kullanılarak yeni bir veritabanı sunucusu oluşturulur.

Sonraki Adımlar

Aşağıdakiler hakkında daha fazla bilgi edinin:

Kullanılabilirlik Alanları) destekleyen Azure Hizmetleri