Azure Batch'te güvenilirlik
Bu makalede Azure Batch'teki güvenilirlik desteği açıklanır ve hem kullanılabilirlik alanlarıyla bölgesel dayanıklılık hem de bölgeler arası kurtarma ve iş sürekliliği hakkındaki bilgilerin bağlantıları ele alınmaktadır.
Kullanılabilirlik alanı desteği
Azure kullanılabilirlik alanları, her Azure bölgesindeki en az üç fiziksel ayrı veri merkezi grubudur. Her bölgedeki veri merkezleri bağımsız güç, soğutma ve ağ altyapısı ile donatılmıştır. Yerel bölge hatası durumunda kullanılabilirlik alanları, bir bölge etkileniyorsa, bölgesel hizmetler, kapasite ve yüksek kullanılabilirlik kalan iki bölge tarafından desteklenecek şekilde tasarlanmıştır.
Hatalar, yazılım ve donanım arızalarından deprem, sel ve yangın gibi olaylara kadar değişebilir. Azure hizmetlerinin yedekliliği ve mantıksal yalıtımı ile hatalara dayanıklılık elde edilir. Azure'daki kullanılabilirlik alanları hakkında daha ayrıntılı bilgi için bkz . Bölgeler ve kullanılabilirlik alanları.
Azure kullanılabilirlik alanlarının etkinleştirildiği hizmetler, doğru güvenilirlik ve esneklik düzeyini sağlayacak şekilde tasarlanmıştır. Bunlar iki şekilde yapılandırılabilir. Alanlar arasında otomatik çoğaltma ile alanlar arası yedekli veya belirli bir bölgeye sabitlenmiş örneklerle bölgesel olabilir. Bu yaklaşımları da birleştirebilirsiniz. Bölgesel ve alanlar arası yedekli mimari hakkında daha fazla bilgi için bkz. kullanılabilirlik alanlarını ve bölgelerini kullanmak için Öneriler.
Batch, kullanılabilirlik alanlarını desteklemek için Azure ile eşliği korur.
Önkoşullar
Kullanıcı aboneliği modu Batch hesapları için havuzunuzu oluşturmakta olduğunuz aboneliğin istenen VM SKU'su üzerinde bölge teklifi kısıtlaması olmadığından emin olun. Aboneliğinizde herhangi bir kısıtlama olup olmadığını görmek için Kaynak Sku'ları Listesi API'sini çağırın ve öğesini
ResourceSkuRestrictionsdenetleyin. Bölge kısıtlaması varsa, bölge kısıtlamasını kaldırmak için bir destek bileti gönderebilirsiniz.InfiniBand bölgeler arası iletişimi desteklemediğinden, düğümler arası iletişim etkinse ve InfiniBand'i destekleyen bir VM SKU'su kullanıyorsa, bölge ilkesine sahip bir havuz oluşturamazsınız.
Batch, kullanılabilirlik alanlarını desteklemek için Azure ile eşliği korur. Bölgesel seçeneği kullanmak için havuzunuzun kullanılabilirlik alanı desteğine sahip bir Azure bölgesinde oluşturulması gerekir.
Batch havuzunuzu kullanılabilirlik alanları arasında ayırmak için havuzun oluşturulduğu Azure bölgesinin birden fazla bölgede istenen VM SKU'sunu desteklemesi gerekir. Bölgenin birden fazla bölgede istenen VM SKU'yu desteklediğini doğrulamak için Kaynak Sku'ları Listesi API'sini çağırın ve alanını
resourceSkudenetleyinlocationInfo. İstenen VM SKU'su için birden fazla bölgenin desteklendiğinden emin olun. Azure CLI'yi aşağıdaki komutla tüm kullanılabilir Kaynak SKU'larını listelemek için de kullanabilirsiniz:az vm list-skus
Kullanılabilirlik alanları arasında Azure Batch havuzu oluşturma
Kullanılabilirlik alanları arasında Batch havuzu oluşturma örnekleri için bkz . Kullanılabilirlik alanları arasında Azure Batch havuzu oluşturma.
Azure portalı, Azure CLI, PowerShell veya Batch yönetim API'siyle Batch hesapları oluşturma hakkında daha fazla bilgi edinin.
Bölge azaltma deneyimi
Bir bölge kesintisi sırasında, bu bölgedeki düğümler kullanılamaz duruma gelir. Aynı düğüm havuzundaki diğer bölgelere ait düğümler etkilenmez ve kullanılabilir olmaya devam eder.
Azure Batch hesabı, kesinti nedeniyle kapanan düğümleri telafi etmek için yeni düğümleri yeniden dağıtmaz veya oluşturmaz. Kullanıcıların düğüm havuzuna daha fazla düğüm eklemesi gerekir ve bunlar daha sonra diğer iyi durumdaki bölgelerden ayrılır.
Hataya dayanıklılık
Olası bir kullanılabilirlik alanı hatasına hazırlanmak için, çözümün 1/3 kapasite kaybına dayanadığından ve bölge genelinde kesintiler sırasında performansı düşürmeden çalışmaya devam ettiğinden emin olmak için fazla hizmet kapasitesi sağlamanız gerekir. Platform VM'leri üç bölgeye yaydığından ve en az bir bölgenin hatasını hesaba katmak gerektiğinden, en yüksek iş yükü örneği sayısını bir faktörle çarpın/(zones-1) veya 3/2. Örneğin, tipik tepe iş yükünüz dört örnek gerektiriyorsa altı örnek sağlamalısınız: (2/3 * 6 örnek) = 4 örnek.
Kullanılabilirlik alanı geçişi
Mevcut batch havuzunu kullanılabilirlik alanı desteğine geçiremezsiniz. Batch havuzunuzu kullanılabilirlik alanları arasında yeniden oluşturmak istiyorsanız bkz . Kullanılabilirlik alanları arasında Azure Batch havuzu oluşturma.
Bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği
Azure Batch tüm Azure bölgelerinde kullanılabilir. Ancak, bir Batch hesabı oluşturulduğunda, belirli bir bölgeyle ilişkilendirilmelidir. Bu Batch hesabı için sonraki tüm işlemler yalnızca o bölgeye uygulanır. Örneğin, havuzlar ve ilişkili sanal makineler (VM) Batch hesabıyla aynı bölgede oluşturulur.
Batch kullanan bir uygulama tasarlarken, Batch'in bir bölgede kullanılamama olasılığını göz önünde bulundurmanız gerekir. Bölgenin tamamı, bölgedeki Batch hizmetinin tamamı veya belirli bir Batch hesabınızla ilgili bir sorun olduğu nadir bir durumla karşılaşabilirsiniz.
Batch kullanan uygulama veya çözümün her zaman kullanılabilir olması gerekiyorsa, başka bir bölgeye yük devretme veya iş yükünün her zaman iki veya daha fazla bölgeye bölünmesi için tasarlanmalıdır. Her iki yaklaşımda da her hesap farklı bir bölgede bulunan en az iki Batch hesabı gerekir.
Azure Batch ile bölgeler arası olağanüstü durum kurtarmayı ayarlamak sizin sorumluluğundadır. Belirli bölgelerde birden çok Batch hesabı çalıştırıyor ve kullanılabilirlik alanlarından yararlanıyorsanız, Batch hesaplarınızdan biri kullanılamaz duruma geldiğinde uygulamanız olağanüstü durum kurtarma hedeflerinizi karşılayabilir.
Alternatif bir bölgeye yük devretme olanağı sağlarken, bir çözümdeki tüm bileşenler dikkate alınmalıdır; yalnızca ikinci bir Batch hesabına sahip olmak yeterli değildir. Örneğin, çoğu Batch uygulamasında bir Azure depolama hesabı gereklidir. Kabul edilebilir performans için depolama hesabı ve Batch hesabı aynı bölgede olmalıdır.
Yük devretme yapabilecek bir çözüm tasarlarken aşağıdaki noktaları göz önünde bulundurun:
Batch hesabı ve depolama hesabı gibi her bölgedeki tüm gerekli hizmetleri önceden oluşturun. Hesapların oluşturulması için genellikle ücret alınmaz ve yalnızca hesap kullanıldığında veya veriler depolandığında tahakkuk eder.
Batch hesabını kullanarak gerekli çekirdek sayısını ayırmak için tüm kullanıcı aboneliği Batch hesapları için uygun kotaların önceden ayarlandığından emin olun.
Uygulamanın bir bölgede dağıtımını otomatikleştirmek için şablonları ve/veya betikleri kullanın.
Uygulama ikili dosyalarını ve başvuru verilerini tüm bölgelerde güncel tutun. Güncel kalmak, dosyaların karşıya yüklenmesini ve dağıtılmasını beklemek zorunda kalmadan bölgenin hızlı bir şekilde çevrimiçi olmasını sağlar. Örneğin, havuz düğümlerine yüklenecek özel bir uygulamanın Batch uygulama paketleri kullanılarak depolandığı ve başvurulduğu durumu göz önünde bulundurun. Uygulamanın bir güncelleştirmesi yayımlandığında, her Batch hesabına yüklenmelidir ve havuz yapılandırması tarafından başvurulmalıdır (veya en son sürümü varsayılan sürüm yapmalısınız).
Batch, depolama ve diğer hizmetleri çağıran uygulamada, istemcilerin veya yükün farklı bölgelere geçişini kolaylaştırın.
Normal işlemin bir parçası olarak sık sık alternatif bir bölgeye geçmeyi göz önünde bulundurun. Örneğin, ayrı bölgelerde iki dağıtımla, her ay alternatif bölgeye geçiş yapın.
Olağanüstü durumdan kurtarma süresi, seçtiğiniz kuruluma bağlıdır. Batch'in kendisi, birden çok hesap mı yoksa tek bir hesap mı kullandığınız konusunda belirsizdir. İki Batch örneğinin aynı anda trafik aldığı etkin-etkin yapılandırmalarda olağanüstü durum kurtarma, etkin-pasif yapılandırmadan daha hızlıdır. Seçtiğiniz yapılandırma, iş gereksinimlerine (farklı bölgeler, gecikme süresi gereksinimleri) ve teknik konulara göre olmalıdır.
Tek bölgeli olağanüstü durum kurtarma
Tek bölgeli veya çok bölgeli bir coğrafyada çalışıyor olun, Batch'te olağanüstü durum kurtarmayı uygulama yönteminiz aynıdır. Tek fark, depolama için hangi SKU'yu kullandığınız ve tüm bölgelerde aynı veya farklı depolama hesabını kullanmak isteyip istemediğinizdir.
Olağanüstü durum kurtarma testi
Batch özellikli çözümünüzün kendi olağanüstü durum kurtarma testini gerçekleştirmeniz gerekir. Farklı bölgelerde istemci ve hizmet yükü arasında kolay geçiş yapmak en iyi yöntem olarak kabul edilir.
Batch için olağanüstü durum kurtarma planınızı test etmek, batch hesaplarını değiştirmek kadar basit olabilir. Örneğin, bir işlem günü için belirli bir bölgedeki tek bir Batch hesabına güvenebilirsiniz. Ardından, sonraki gün farklı bir bölgede ikinci bir Batch hesabına geçebilirsiniz. Olağanüstü durum kurtarma öncelikli olarak istemci tarafında yönetilir. Olağanüstü durum kurtarma için bu çok hesaplı yaklaşım, tek bölgeli veya çok bölgeli coğrafyalardaki RTO ve RPO beklentilerini üstlenir.
Kapasite ve proaktif olağanüstü durum kurtarma dayanıklılığı
Microsoft ve müşterileri Paylaşılan Sorumluluk modeli altında çalışır. Microsoft, platform ve altyapı dayanıklılığının sorumluluğundadır. Dağıtıp denetlediğiniz belirli bir hizmet için olağanüstü durum kurtarmayı ele almak sizin sorumluluğundadır. Kurtarmanın proaktif olduğundan emin olmak için:
İkincilleri her zaman önceden dağıtmalısınız. İkincillerin ön dağıtımı gereklidir, çünkü bu tür kaynakları önceden ayırmamış olanlar için etki anında kapasite garantisi yoktur.
Batch hesaplarınız ve ilişkili depolama hesaplarınız gibi her bölgedeki tüm gerekli hizmetleri önceden oluştur. Yeni hesap oluşturmak için ücret alınmaz; yalnızca hesap kullanıldığında veya veriler depolandığında tahakkuk eder.
Batch hesabını kullanarak gerekli çekirdek sayısını ayırabilmeniz için tüm aboneliklerde önceden uygun kotaların ayarlandığından emin olun. Diğer Azure hizmetlerinde olduğu gibi Batch hizmetiyle ilişkili belirli kaynaklarda da sınırlamalar vardır. Bu sınırların çoğu Azure tarafından abonelik veya hesap düzeyinde uygulanan varsayılan kotalardır. Batch iş yüklerinizi tasarlayıp ölçeklendirirken bu kotaları göz önünde bulundurun.
Not
Batch'te üretim iş yüklerini çalıştırmayı planlıyorsanız, kotalardan birini veya daha fazlasını varsayılanın üzerinde artırmanız gerekebilir. Kota artırmak için ücretsiz olarak kota artışı isteyebilirsiniz. Daha fazla bilgi için bkz . Kota artışı isteme.
Depolama
Verilerin bölgeler arası yedeklendiğinden emin olmak için Batch depolamayı yapılandırmanız gerekir; müşteri sorumluluğu varsayılandır. Çoğu Batch çözümü, kaynak dosyalarını ve çıkış dosyalarını depolamak için Azure Depolama kullanır. Örneğin, Batch görevleriniz (standart görevler, başlangıç görevleri, iş hazırlama görevleri ve iş bırakma görevleri dahil) genellikle depolama hesabında yer alan kaynak dosyalarını belirtir. Depolama hesapları ayrıca işlenen verileri ve oluşturulan çıkış verilerini de depolar. Hizmet işlemlerinizin bölgeleri arasında olası veri kaybını anlamak önemli bir noktadır. Ayrıca verilerin yeniden yazılabilir mi yoksa salt okunur mu olduğunu onaylamanız gerekir.
Batch, aşağıdaki Azure Depolama hesap türlerini destekler:
- Genel amaçlı v2 (GPv2) hesapları
- Genel amaçlı v1 (GPv1) hesapları
- Blob depolama hesapları (şu anda Sanal Makine yapılandırmasındaki havuzlar için desteklenmektedir)
Depolama hesapları hakkında daha fazla bilgi için bkz. Azure Depolama hesabına genel bakış.
Bir depolama hesabını, hesabı oluştururken Batch hesabınızla ilişkilendirebilir veya bu adımı daha sonra gerçekleştirebilirsiniz.
Hizmetinizin kullanılabilir olduğu her bölge için ayrı bir depolama hesabı oluşturuyorsanız alanlar arası yedekli depolama (ZRS) hesaplarını kullanmanız gerekir. Aynı depolama hesabını birden çok eşleştirilmiş bölgede kullanıyorsanız coğrafi alanlar arası yedekli depolama (GZRS) hesaplarını kullanın. Tek bir bölge içeren coğrafyalar için, GZRS kullanılamadığından alanlar arası yedekli depolama (ZRS) hesabı oluşturmanız gerekir.
Kapasite planlaması, depolama ile ilgili dikkat edilmesi gereken bir diğer önemli noktadır ve proaktif olarak ele alınmalıdır. Bir depolama hesabı seçerken, maliyet ve performans gereksinimlerinizi göz önünde bulundurun. Örneğin, GPv2 ve blob depolama hesabı seçenekleri, GPv1’e kıyasla daha büyük kapasite ve ölçeklenebilirlik sınırlarını destekler. (Depolama sınırında artış istemek için Azure Desteği'ne başvurun.) Bu hesap seçenekleri, depolama hesabından okuyan veya bu hesaba yazan çok sayıda paralel görev içeren Batch çözümlerinin performansını geliştirebilir.
Depolama hesabı bir Batch hesabına bağlandığında, bunu otomatik fırtına hesabı olarak düşünün. Uygulama paketi .zip dosyaları depolamak için kullanıldığından , uygulama paketleri özelliğini kullanmayı planlıyorsanız bir otomatik fırtına hesabı gereklidir. Otomatik fırtına hesabı, görev kaynak dosyaları için de kullanılabilir; otomatik fırtınası hesabı batch hesabına zaten bağlı olduğundan, kaynak dosyalarına erişmek için paylaşılan erişim imzası (SAS) URL'lerine ihtiyaç duymayı önler.