Aracılığıyla paylaş

Azure iş yükleri için bölge dayanıklılığını etkinleştirme

Uygulamalarınızı bölgeyle ilgili donanım hatalarına, ağ kesintilerine ve doğal afetlere karşı daha dayanıklı hale getirmek için Azure iş yüklerinizi bölge dayanıklılığı için tasarlamanız önemlidir. Bir bölgedeki birden çok kullanılabilirlik alanına kaynak dağıttığınızda, kritik hizmetleri etkileyen tek bir bölge kesintisi riskini azaltırsınız.

İş yüklerinin ilk planlama ve dağıtımı sırasında bölge dayanıklılığını ele almak en iyi yöntem olsa da, mevcut dayanıklı olmayan iş yüklerini bölge dayanıklı yapılandırmalara dönüştürmek yaygın bir yöntemdir. Genel olarak, mevcut iş yükleri için bölge dayanıklılığını etkinleştirme işlemi basittir ve Microsoft süreci basitleştirmeye devam eder. Ancak, iş yükünüzde yapılan herhangi bir değişiklik bir risk miktarına neden olabilir. İlgili riskleri anladıktan sonra, bu iş yükleri içindeki hangi iş yüklerinin ve hizmetlerin işletmeniz için en önemli olduğunu değerlendirebilecek ve önceliklerini belirtebilecek, ardından önce en etkili kaynaklara bölge dayanıklılığı uygulayabileceksiniz.

Bu makalede, Azure iş yüklerinizde bölge dayanıklılığını etkinleştirmeye yönelik önemli noktalar özetlenmiştir. Ayrıca daha dayanıklı bir mimariye başarılı bir geçiş planlamanıza ve uygulamanıza da yardımcı olur.

Tavsiye

Şu anda iş yüklerinizi tasarlama aşamasındaysanız veya geçerli iş yüklerinizin tasarım gözden geçirmesini yapmayı planlıyorsanız , Azure Well-Architected Framework'te (WAF) yedeklilik için tasarım önerilerine uymanız önemlidir. WAF önerileri kılavuzu, kritik iş akışlarına odaklanarak birden çok düzeyde iş yükü yedekliliği tasarlamanıza yardımcı olur. Kullanılabilirlik alanı benimsemesini desteklemek için, çok bölgeli dağıtımlar ve dağıtım damgaları gibi stratejileri de özetler.

Bölge dayanıklılığı nedir?

Azure hizmetleri, kullanılabilirlik alanı kesintilerine karşı iki birincil yolla dayanıklı hale getirilebilir:

  • Alanlar arası yedekli hizmetler: Birçok Azure hizmeti alanlar arası yedekliliği destekler. Bu hizmetler kullanılabilirlik alanları arasında verileri otomatik olarak çoğaltır, gelen istekleri dağıtır ve bölge hatası sırasında farklı bölgelere yük devreder. Her hizmet, bu özellikleri söz konusu hizmet için anlamlı bir şekilde destekler. Bazı hizmetler varsayılan olarak alanlar arası yedeklidir, diğer hizmetler ise bölge yedekliliğini yapılandırmanıza ihtiyaç duyabilir.

  • Bölgesel hizmetler: Bazı Azure hizmetleri bölgeseldir ve bu da belirli bir kullanılabilirlik alanına sabitlenebileceği anlamına gelir. Bölgesel bir hizmet kullanarak bölge dayanıklılığını elde etmek için hizmetin ayrı örneklerini birden çok kullanılabilirlik alanına dağıtın. Ayrıca trafik dağıtımını, verilerin çoğaltılmasını ve örnekler arasında yük devretmeyi yönetmeniz gerekebilir.

Bazı hizmetler alanlar arası yedekli veya bölgesel yapılandırmada dağıtılabilir. Çoğu durumda, alanlar arası yedekli hizmetleri dağıtabildiğiniz zaman dağıtmak en iyisidir.

Daha fazla bilgi için bkz. Kullanılabilirlik alanı desteği türleri.

Bölge etkinleştirme yordamı

Azure iş yüklerinizi sistematik olarak gözden geçirmek, bölge dayanıklılığına öncelik vermek ve her bileşen için bölge dayanıklılığını etkinleştirmek için aşağıdaki adımları kullanın.

Önkoşullar

Başlamadan önce aşağıdaki eylemleri gerçekleştirin:

  • Her iş yükünü tanımlayın. İş yükü, tanımlı iş sonuçları elde etmek için birlikte işlev gösteren uygulama kaynakları, veriler ve destekleyici altyapı koleksiyonunu ifade eder. İş yükleri ve bunların nasıl tanımlanacağı hakkında daha fazla bilgi için bkz. Well-Architected Framework iş yükleri.

  • Her iş yükünün kullanıcı ve sistem akışlarının önceliğini belirleyin. Öncelikle hangi bileşenlerin bölgeyi dayanıklı hale getireceğini belirlemek için iş yüklerinizin kritik yollarını ve bağımlılıklarını anlayın. İş akışlarını önceliklendirmek için kritik akış analizini kullanma hakkında daha fazla bilgi için bkz. Bölge dayanıklılığı için iş yüklerini önceliklendirme.

  • Her iş yüküne ve akışa bir kritiklik derecelendirmesi atayın. Bu derecelendirme, olası bir kesintinin işletmeniz üzerindeki etkisini anlamanıza yardımcı olur ve bölge dayanıklılığı için hangi iş yüklerine öncelik verebileceğiniz konusunda kararlarınıza yol gösterir. Ayrıca iş yüklerini yeniden yapılandırırken kabul edilebilir kapalı kalma süresini de göz önünde bulundurun.

    İş yüklerinizi kritikliklerine göre sınıflandırmak için taksonomi kullanabilirsiniz. Bu yaklaşım, çalışmalarınızı en önemli hizmetlere odaklamanıza yardımcı olur.

    İş yüklerinizi sınıflandırmak için aşağıdaki örnek taksonomiyi göz önünde bulundurun.

    İş yükü türü Description Kesintinin etkisi
    Görev açısından kritik Son derece güvenilir, her zaman kullanılabilir, hatalara dayanıklı ve çalışır durumda olması gereken kritik akışlar ve iş yükleri Temel işlevlerde meydana gelen herhangi bir kesinti, iş açısından yıkıcı zarara neden olabilir veya insan hayatına yönelik riskler getirir.
    İş açısından kritik Önemli iş işlevlerini çalıştıran temel akışlar ve iş yükleri Kesinti, bazı finansal kayıplar veya marka zararları riski taşır.
    İş açısından operasyonel İş operasyonlarının verimliliğine katkıda bulunur, ancak müşterilere doğrudan hizmet dışıdır Bazı kesinti düzeylerini tolere edebilir.
    Yönetimsel İş operasyonlarıyla uyumlu olmayan iç üretim akışları ve iş yükleri Kesintiye dayanabilir.

    İş yüklerinizi kritiklik derecelendirmesine göre sınıflandırma hakkında daha fazla bilgi için bkz. Her akışa bir kritiklik derecelendirmesi atama.

  • Azure kaynaklarınızın bulunduğu bölgelerin kullanılabilirlik alanlarını desteklediğini doğrulayın. Azure bölgeleri listesine bakın. Bir bölge kullanılabilirlik alanlarını desteklemiyorsa kaynaklarınızı bunu destekleyen bir bölgeye yeniden konumlandırmayı göz önünde bulundurun. Daha fazla bilgi için bkz. Azure kaynaklarını kaynak grupları, abonelikler veya bölgeler arasında taşıma.

1. Adım: Bölge dayanıklılığı için Azure hizmetlerinin önceliğini belirleme

İşletmeniz için en kritik iş yükü akışlarını belirledikten sonra, bu akışların bağımlı olduğu Azure hizmetlerine odaklanabilirsiniz. Bazı Azure hizmetleri uygulamalarınız için diğerlerinden daha önemlidir. Bölge hatası oluşması durumunda uygulamalarınızın kullanılabilir ve dayanıklı kalmasını sağlamaya yardımcı olmak için bu hizmetlerin önceliklerini belirleyin.

Azure hizmet gruplarının iş yükleriniz için önem derecesine göre önceliklerini belirlemeye yönelik aşağıdaki kılavuzu kullanın. Bölge dayanıklılığı için hizmetlerin önceliğini belirlerken belirli uygulama mimarinizi ve iş gereksinimlerinizi göz önünde bulundurun.

  1. Ağ hizmetleriyle başlayın. İş yükleri ağ hizmetlerini paylaşma eğilimindedir, bu nedenle bu hizmetlerin dayanıklılığındaki artış aynı anda birden çok iş yükünün dayanıklılığını artırabilir.

    Çoğu çekirdek ağ hizmeti otomatik olarak alanlar arası yedeklidir, ancak Azure ExpressRoute ağ geçitleri, Azure VPN Gateway, Azure Application Gateway, Azure Load Balancer ve Azure Güvenlik Duvarı gibi bileşenlere odaklanmalısınız.

  2. İşletimsel veri depolama dayanıklılığını geliştirin. İşletimsel veri depoları, birden çok iş yükünün sıklıkla kullandığı değerli veriler içerir, bu nedenle bu veri depolarının kullanılabilirliğini artırmak birçok iş yüküne yardımcı olabilir.

    İşletimsel veri depolama dayanıklılığı için Azure SQL Veritabanı, Azure SQL Yönetilen Örneği, Azure Depolama, Azure Data Lake Storage, Azure Cosmos DB, Azure PostgreSQL Esnek Sunucusu, Azure MySQL Esnek Sunucusu ve Redis için Azure Cache gibi hizmetlere odaklanın.

  3. İşlem hizmetlerinin önceliğini belirleme. Bu hizmetlerin durum bilgisi olmadığından bölgeler arasında çoğaltılması ve dağıtılması genellikle kolaydır.

    İşlem hizmetleri arasında Azure Sanal Makineler, Azure Sanal Makine Ölçek Kümeleri, Azure Kubernetes Service (AKS), Azure App Service, App Service Ortamı, Azure İşlevleri, Azure Service Fabric ve Azure Container Apps bulunur.

  4. Kritik akışlarınızın kullandığı iş açısından kritik kaynakların kalan kısmını gözden geçirin. Bu kaynaklar daha önce listelenen kaynaklar kadar kritik olmayabilir, ancak yine de uygulamanızın işlevselliğinde bir rol oynarlar ve bunları bölge dayanıklılığı açısından dikkate almanız gerekir.

  5. İşletmenizin işletimsel kaynaklarının geri kalanını gözden geçirin. Bu konuda bilgili kararlar alarak bunları bölge dayanıklı yapıp yapmayacağınızı belirleyin. Bu inceleme, kritik iş yüklerinizle doğrudan ilişkili olmayan ancak genel uygulama performansına ve güvenilirliğine katkıda bulunabilecek hizmetleri içerir.

2. Adım: Bölge yapılandırma yaklaşımlarını değerlendirme

İş yüklerinize ve Azure hizmetlerine öncelik verdikten sonra, her hizmet için kullanılabilirlik alanı desteğini etkinleştirmek için gereken yaklaşımı belirleyin ve bölge dayanıklılığını yapılandırmak için yapmanız gerekenleri anlayın.

Her Azure güvenilirlik hizmeti kılavuzu, bu hizmet için bölge dayanıklılığının nasıl etkinleştirildiğini açıklayan bir bölüm sağlar. Bu bölüm, stratejinizi uygun şekilde planlayabilmek için her bir hizmet bölgesini dayanıklı hale getirmek için gereken çabayı anlamanıza yardımcı olur. Belirli bir hizmet hakkında daha fazla bilgi için bkz. Azure güvenilirlik hizmeti kılavuzları.

Yaygın Azure hizmetlerine yönelik yaklaşımları hızlı bir şekilde anlamak için bölge yapılandırma tablosunu kullanın.

Önemli

İş yükünüz bölgesel (veya tek bölgeli) bir yapılandırmada dağıtılan bileşenler içeriyorsa, bu bileşenleri bölge kesintilerine dayanıklı hale getirmeyi planlayın. Yaygın bir yaklaşım, farklı örnekleri başka bir kullanılabilirlik alanına dağıtmak ve gerekirse bunlar arasında geçiş yapmaktır.

3. Adım: Gecikme süresini test edin

İş yüklerini bölge olarak dayanıklı hale getirdiğinizde, kullanılabilirlik alanları arasındaki gecikme süresini göz önünde bulundurun. Bazı eski sistemler, özellikle veri katmanında zaman uyumlu çoğaltmayı etkinleştirdiğinizde bölgeler arası trafiğin neden olduğu az miktarda ek gecikme süresini tolere edemez. Bölgeler arası gecikme süresinin iş yükünüzü etkileyebileceğinden şüpheleniyorsanız, bölge dayanıklılığını etkinleştirmeden önce ve sonra testleri çalıştırın. Bölgeler arası gecikme süresinin uygulamanızı nasıl etkileyebileceği ve bölgeler arası gecikme süresi sorunlarını azaltmaya yönelik yaklaşımlar hakkında daha fazla bilgi için bkz. Bölgesel kaynaklar ve bölge dayanıklılığı.

Azure hizmetleri için bölge yapılandırma yaklaşımları

Her Azure hizmeti, hizmetin amaçlanan kullanımını ve iç mimarisini temel alan belirli bir kullanılabilirlik alanı desteğini destekler. Kullanılabilirlik alanlarını (veya bölgesel olmayan bir kaynağı) kullanacak şekilde yapılandırılmamış bir kaynağınız varsa, kullanılabilirlik alanı desteğiyle yeniden yapılandırmak isteyebilirsiniz. Bu hizmetin güvenilirlik kılavuzu, kullanılabilirlik alanı yapılandırma yönergelerine yönelik yönergeler veya bağlantılar sağlar.

Bu bölümde, farklı türlerdeki bölge yapılandırma yaklaşımlarına ve her hizmetin desteklediği yaklaşımlara genel bir bakış sağlanmaktadır.

Önemli

Bir kaynakta bölge yedekliliğini etkinleştirdiğinizde, bu kaynak bölge hatalarına karşı otomatik olarak dayanıklı hale gelir. Kaynağı belirli bir kullanılabilirlik alanına sabitlemek için bölgesel yapılandırma kullandığınızda, kaynak otomatik olarak alanlar arası yedekli olmaz. Bölge hatasına dayanıklı hale getirmelisiniz. Bölgesel hizmetler için bu makale, bir bölgeye sabitlemenin karmaşıklığını ve maliyetini yansıtır. Bölge dayanıklılığını elde etmeye yönelik ek adımlar hakkında daha fazla bilgi için hizmetin güvenilirlik kılavuzuna bakın.

Bölge yapılandırma tablosu, birçok Azure hizmeti için desteklenen bölge yapılandırma yaklaşımını listeler ve bu hizmet için her güvenilirlik kılavuzunun bağlantısını içerir. Güvenilirlik kılavuzu, kullanılabilirlik alanı desteğini etkinleştirmek için bölgesel olmayan hizmet kaynaklarını yapılandırma hakkında bilgi sağlar.

Aşağıdaki tabloda, kullanılabilirlik alanlarını etkinleştirmek için gereken çalışma düzeyi ve kapalı kalma süresi de dahil olmak üzere her bölge yapılandırma yaklaşımı açıklanmaktadır.

Yaklaşım Description Tipik efor düzeyi Kapalı kalma süresi gerektirebilir
Her zaman bölgesel yedekli Varsayılan olarak, kullanılabilirlik alanlarını destekleyen bölgelerde hizmet bölgeye dayanıklıdır. Eylem gerekmez. Hiç kimse Hayı
Enablement Ayarlarda alanlar arası yedekliliği etkinleştirme gibi en az yapılandırma değişikliği gereklidir. İşlem kullanılabilirliği etkilemez, ancak maliyet veya performans üzerindeki etkileri göz önünde bulundurun. Low Hayı
Değişiklik Büyük olasılıkla bağımlı kaynakları yeniden dağıtma veya ağ ayarlarını değiştirme gibi bazı yapılandırma değişiklikleri gerektirir. Orta Yes
Reorganizasyon Kaynakların, uygulamaların veya hizmetlerin tamamını yeniden dağıtma veya verileri yeni hizmetlere geçirme gibi önemli değişiklikler gereklidir. High Yes

Bir hizmet için kullanılabilirlik alanı desteğini etkinleştirmenin maliyetini anlayın. Birçok hizmet için kullanılabilirlik alanlarının etkinleştirilmesi maliyet eklemez. Ancak bazı hizmetler belirli bir katmana, belirli sayıda kapasite birimine veya her ikisine de ihtiyaç duyar. Kullanılabilirlik alanlarını kullandığınızda diğer hizmetler farklı fiyatlarla ücretlendirilir. Sonraki bölümdeki tabloda her hizmet için tipik maliyet etkisi listelenir.

Uyarı

Bu makaledeki bilgiler, kullanılabilirlik alanı desteğini etkinleştirmeye yönelik tipik yaklaşımı özetler ve tipik maliyet etkisini özetler. Ancak bazı faktörler, çözümünüz için nasıl çalıştığını etkileyebilir. Örneğin, bazı hizmetler her zaman bölge dayanıklı olarak listelenir, ancak bu atama yalnızca belirli bölgelerde veya hizmetin belirli katmanları için geçerlidir. Bu tabloları başlangıç noktası olarak kullanın, ancak belirli ayrıntıları anlamak için bahsedilen diğer kaynakları gözden geçirin.

Bölge yapılandırmasına göre Azure hizmetleri yaklaşımı

Aşağıdaki tabloda birçok Azure hizmetinin kullanılabilirlik alanı desteği özetlenmektedir ve her hizmet için kullanılabilirlik alanı desteğini etkinleştirmek için maliyet etkisi de dahil olmak üzere bir yaklaşım sunulmaktadır.

Hizmet Alanlar arası yedekli olabilir Bölgesel olabilir Tipik bölge yapılandırma yaklaşımı Tipik maliyet etkisi
Azure AI Arama Hizmeti Evet Her zaman bölgesel yedekli Mevcut Değil
Azure API Management Evet Evet Değişiklik Gereken en düşük katman
Azure Uygulaması Yapılandırması Evet Her zaman bölgesel yedekli Mevcut Değil
Azure App Service Evet Enablement Gerekli minimum katman ve örnek sayısı
Azure Uygulama Hizmeti - Uygulama Hizmeti Ortamı Evet Enablement Gerekli en düşük örnek sayısı
Azure Uygulama Ağ Geçidi Evet Evet Her zaman bölgesel yedekli Mevcut Değil
Azure Backup Evet Reorganizasyon Orta maliyet artışı
Azure Bastion Evet Evet Reorganizasyon Maliyet etkisi yok
Azure Batch Evet Reorganizasyon Aynı sayıda sanal makine (VM) için maliyet etkisi yoktur
Azure Blob Depolama Evet Enablement Orta maliyet artışı
Redis için Azure Cache - Kurumsal Evet Reorganizasyon Maliyet etkisi yok
Redis için Azure Cache - Standart ve Premium Evet Enablement Gereken en düşük katman
Azure Container Apps Evet Reorganizasyon En az kopya sayısı gereklidir
Azure Container Instances Evet Reorganizasyon Maliyet etkisi yok
Azure Container Registry Evet Her zaman bölgesel yedekli Mevcut Değil
NoSQL için Azure Cosmos DB Evet Değişiklik Otomatik ölçeklendirme veya çok bölgeli yazımlar kullanılıyorsa hiçbiri
Azure Data Factory Evet Her zaman bölgesel yedekli Mevcut Değil
Azure Data Lake Storage Evet Enablement Orta maliyet artışı
MySQL için Azure Veritabanı - Esnek Sunucu Evet Reorganizasyon Birincil ve yüksek kullanılabilirlik (HA) örneği gerektirir
PostgreSQL için Azure Veritabanı - Esnek Sunucu Evet Enablement Birincil ve HA instansı gerektirir
Azure Databricks Evet Enablement Aynı sayıda VM için maliyet etkisi yoktur; depolama için orta maliyet artışı
Azure Disk Depolama (yönetilen diskler) Evet Evet Enablement Orta maliyet artışı
Azure Elastik SAN Evet Reorganizasyon Orta maliyet artışı
Azure Event Hubs: Özel katman Evet Her zaman bölgesel yedekli Gereken en düşük kapasite birimleri (RU)
Azure Event Hubs: diğer tüm katmanlar Evet Her zaman bölgesel yedekli Mevcut Değil
Azure ExpressRoute ağ geçidi Evet Evet Değişiklik Katmana göre değişir
Azure Dosyaları Evet Enablement Orta maliyet artışı
Azure Güvenlik Duvarı Evet Evet Değişiklik Maliyet etkisi yok
Azure İşlevleri Evet Reorganizasyon Gerekli minimum katman ve örnek sayısı
Azure HDInsight Evet Reorganizasyon Aynı sayıda düğüm için maliyet etkisi yoktur
Azure IoT Hub Evet Her zaman bölgesel yedekli Mevcut Değil
Azure Key Vault Evet Her zaman bölgesel yedekli Mevcut Değil
Azure Kubernetes Service (AKS) Evet Reorganizasyon Maliyet etkisi yok
Azure Load Balancer Evet Evet Değişiklik Maliyet etkisi yok
Azure Logic Apps - Tüketim katmanı Evet Her zaman bölgesel yedekli Mevcut Değil
Azure Logic Apps - Standart katman Evet Reorganizasyon Gerekli minimum katman ve örnek sayısı
Azure Yönetimli Grafana Evet Yeniden dağıtım Orta maliyet artışı
Azure İzleyici: Log Analytics Evet Her zaman bölgesel yedekli
Azure NAT Ağ Geçidi Evet Evet Reorganizasyon Maliyet etkisi yok
Azure NetApp Files Evet Reorganizasyon Çoğaltma yapılandırmasına bağlıdır
Azure Kuyruk Depolama Evet Enablement Orta maliyet artışı
Azure Service Bus Evet Her zaman bölge dayanıklı Mevcut Değil
Azure Service Fabric Evet Evet Reorganizasyon Aynı sayıda VM için maliyet etkisi yoktur
Azure Site Recovery Evet Reorganizasyon Site Recovery için maliyet etkisi yok, replika depolama için orta düzeyde bir maliyet artışı.
Azure SQL Veritabanı: İş Açısından Kritik katman Evet Enablement Maliyet etkisi yok
Azure SQL Veritabanı: Genel Amaçlı katman Evet Enablement Orta maliyet artışı
Azure SQL Veritabanı: Hiper Ölçek katmanı Evet Reorganizasyon En az kopya sayısı gereklidir
Azure SQL Veritabanı: Premium katman Evet Enablement Maliyet etkisi yok
Yönetilen Azure SQL Örneği Evet Enablement Orta maliyet artışı
Azure Stream Analytics Evet Her zaman bölge dayanıklı Mevcut Değil
Azure Tablo Depolama Evet Enablement Orta maliyet artışı
Azure Sanal Makine Ölçek Kümeleri Evet Evet Reorganizasyon Aynı sayıda VM için maliyet etkisi yoktur
Azure Sanal Makineler Evet Reorganizasyon Aynı sayıda VM için maliyet etkisi yoktur
Azure Sanal Ağ Evet Her zaman bölgesel yedekli Mevcut Değil
Genel IP adresi Evet Evet Her zaman bölgesel yedekli Mevcut Değil
  • Last updated on