Belirli Azure hizmetleri için dayanıklılık denetim listesi

Dayanıklılık, bir sistemin hatalardan kurtularak çalışmaya devam edebilme özelliğidir. Her teknolojinin, uygulamanızı tasarlarken ve uygularken göz önünde bulundurmanız gereken kendi hata modları vardır. Belirli Azure hizmetlerinin dayanıklılık konularını gözden geçirmek için bu denetim listesini kullanın. Dayanıklı uygulamalar tasarlama hakkında daha fazla bilgi için bkz . Güvenilir Azure uygulamaları tasarlama.

App Service

Standart veya Premium katmanı kullanın. Bu katmanlar hazırlama yuvalarını ve otomatik yedeklemeleri destekler. Daha fazla bilgi için bkz. Azure Uygulaması Hizmet planlarında ayrıntılı genel bakış

Ölçeği artırmaktan veya küçültmekten kaçının. Bunun yerine, tipik yük altında performans gereksinimlerinizi karşılayan bir katman ve örnek boyutu seçin ve ardından trafik hacmindeki değişiklikleri işlemek için örneklerin ölçeğini genişletin . Ölçeği artırma ve azaltma, uygulamanın yeniden başlatılmasını tetikleyebilir.

Yapılandırmayı uygulama ayarları olarak depolayın. Yapılandırma ayarlarını uygulama ayarları olarak tutmak için uygulama ayarlarını kullanın. Resource Manager şablonlarınızdaki ayarları tanımlayın veya PowerShell kullanarak bunları daha güvenilir olan otomatik dağıtım /güncelleştirme işleminin bir parçası olarak uygulayabilirsiniz. Daha fazla bilgi için bkz. Azure Uygulaması Hizmetinde web uygulamalarını yapılandırma.

Üretim ve test için ayrı App Service planları oluşturun. Test için üretim dağıtımınızda yuvaları kullanmayın. Aynı app service planındaki tüm uygulamalar aynı VM örneklerini paylaşır. Üretim ve test dağıtımlarını aynı plana koyarsanız, bu durum üretim dağıtımını olumsuz etkileyebilir. Örneğin, yük testleri canlı üretim sitesini düşürebilir. Test dağıtımlarını ayrı bir plana yerleştirerek bunları üretim sürümünden yalıtabilirsiniz.

Web uygulamalarını web API'lerinden ayırın. Çözümünüzde hem web ön ucu hem de web API'si varsa bunları ayrı App Service uygulamalarına ayırmayı göz önünde bulundurun. Bu tasarım, çözümü iş yüküne göre ayrıştırma işlemini kolaylaştırır. Web uygulamasını ve API'yi ayrı App Service planlarında çalıştırarak bağımsız olarak ölçeklendirilebilmelerini sağlayabilirsiniz. İlk başta bu ölçeklenebilirlik düzeyine ihtiyacınız yoksa, uygulamaları aynı plana dağıtabilir ve gerekirse daha sonra ayrı planlara taşıyabilirsiniz.

Alanlar arası yedekli App Service planlarını dağıtma. Desteklenen bölgelerde App Service planları alanlar arası yedekli olarak dağıtılabilir ve bu da örneklerin kullanılabilirlik alanları arasında otomatik olarak dağıtılacağı anlamına gelir. App Service trafiği bölgeler arasında otomatik olarak dağıtır ve bir bölgede kesinti yaşandığında yük devretmeyi işler. Daha fazla bilgi için bkz . App Service'i kullanılabilirlik alanı desteğine geçirme.

Azure SQL veritabanlarını yedeklemek için App Service yedekleme özelliğini kullanmaktan kaçının. Bunun yerine SQL Veritabanı otomatik yedeklemeleri kullanın. App Service yedeklemesi veritabanını DTU'lara mal olan bir SQL BACPAC dosyasına aktarır.

Hazırlama yuvasına dağıtın. Hazırlama için bir dağıtım yuvası oluşturun. Uygulama güncelleştirmelerini hazırlama yuvasına dağıtın ve dağıtımı üretime geçirmeden önce doğrulayın. Bu, üretimde kötü bir güncelleştirme olasılığını azaltır. Ayrıca üretime değiştirilmeden önce tüm örneklerin ısınmasını sağlar. Birçok uygulamada önemli bir ısınma ve soğuk başlangıç zamanı vardır. Daha fazla bilgi için bkz. Azure Uygulaması Service'te web uygulamaları için hazırlama ortamlarını ayarlama.

Bilinen son iyi (LKG) dağıtımı tutmak için bir dağıtım yuvası oluşturun. Bir güncelleştirmeyi üretime dağıttığınızda, önceki üretim dağıtımını LKG yuvasına taşıyın. Bu, kötü bir dağıtımı geri almayı kolaylaştırır. Daha sonra bir sorun bulursanız, hızlı bir şekilde LKG sürümüne geri dönebilirsiniz. Daha fazla bilgi için bkz . Temel web uygulaması.

Uygulama günlüğü ve web sunucusu günlüğü de dahil olmak üzere tanılama günlüğünü etkinleştirin. Günlüğe kaydetme, izleme ve tanılama için önemlidir. Bkz. Azure Uygulaması Hizmeti'nde web uygulamaları için tanılama günlüğünü etkinleştirme

Blob depolamada oturum açın. Bu, verileri toplamayı ve çözümlemeyi kolaylaştırır.

Günlükler için ayrı bir depolama hesabı oluşturun. Günlükler ve uygulama verileri için aynı depolama hesabını kullanmayın. Bu, günlüğün uygulama performansını düşürmesini önlemeye yardımcı olur.

Performansı izleyin. Yük altındaki uygulama performansını ve davranışını izlemek için New Relic veya Application Insights gibi bir performans izleme hizmeti kullanın. Performans izleme, uygulama hakkında gerçek zamanlı içgörüler sağlar. Sorunları tanılamanıza ve hataların kök neden analizini gerçekleştirmenize olanak tanır.

Azure Load Balancer

Standart SKU'yu seçin. Standart yük dengeleyici, Kullanılabilirlik alanları ve bölge dayanıklılığı için Temel'in sağlamadığı bir güvenilirlik boyutu sağlar. Bu, bir bölge kapatıldığında alanlar arası yedekli Standart Load Balancer etkilenmeyeceği anlamına gelir. Bu, dağıtımlarınızın bir bölge içindeki bölge hatalarına dayanabilmesini sağlar. Ayrıca Standart Load Balancer, uygulamanızın bölge hatalarından etkilenmemesini sağlamak için genel yük dengelemeyi destekler.

En az iki örnek sağlayın. Azure Load Balancer'ı arka uçta en az iki örnekle dağıtın. Tek bir örnek tek bir hata noktasına neden olabilir. Ölçek oluşturmak için yük dengeleyiciyi Sanal Makine Ölçek Kümeleri ile eşleştirmeniz gerekir.

Giden kurallarını kullanın. Giden kuralları, Kaynak Ağ Adresi Çevirisi (SNAT) bağlantı noktası tükenmesi nedeniyle bağlantı hatalarıyla karşılaşmamanızı sağlar. Giden bağlantı hakkında daha fazla bilgi edinin. Giden kuralları küçük ve orta ölçekli dağıtımlar için çözümün geliştirilmesine yardımcı olsa da, üretim iş yükleri için Standart yük dengeleyiciyi veya sanal ağ ağ adresi çevirisi (NAT) ile herhangi bir alt ağ dağıtımını birleştirmenizi öneririz.

Azure Genel IP'leri

Standart SKU'yu seçin. Standart Genel IP'ler, Temel Genel IP'lerin aksine kullanılabilirlik alanları ve bölge dayanıklılığı sağlar. Genel IP gerektiren bir hizmet kullanıyorsanız alanlar arası yedekli genel IP'yi seçin. Mevcut IP'ler için, alanlar arası yedeklinin avantajlarından varsayılan olarak yararlanmak için bunları Temel'den Standart'a yükseltin.

Application Gateway

En az iki örnek sağlayın. Application Gateway'i en az iki örnekle dağıtın. Tek bir örnek tek bir hata noktasıdır. Yedeklilik ve ölçeklenebilirlik için iki veya daha fazla örnek kullanın. Hizmet düzeyi sözleşmesine (SLA) hak kazanmak için iki veya daha fazla orta veya daha büyük örnek sağlamalısınız.

Azure Cosmos DB

Alanlar arası yedekliliği yapılandırın. Alanlar arası yedeklilik kullandığınızda, Azure Cosmos DB tüm yazmaları kullanılabilirlik alanları arasında zaman uyumlu bir şekilde çoğaltır. Bölge kesintisi durumunda otomatik olarak yük devreder. Daha fazla bilgi için bkz . Azure Cosmos DB ile yüksek kullanılabilirlik elde edin.

Veritabanını bölgeler arasında çoğaltma. Azure Cosmos DB, istediğiniz sayıda Azure bölgesini bir Azure Cosmos DB veritabanı hesabıyla ilişkilendirmenize olanak tanır. Azure Cosmos DB veritabanının bir yazma bölgesi ve birden çok okuma bölgesi olabilir. Yazma bölgesinde bir hata varsa, başka bir çoğaltmadan okuyabilirsiniz. İstemci SDK'sı bunu otomatik olarak işler. Yazma bölgesinin yükünü başka bir bölgeye de devredebilirsiniz. Daha fazla bilgi için bkz. Azure Cosmos DB ile verileri küresel ölçekte dağıtma.

Event Hubs

Denetim noktalarını kullanın. Olay tüketicisi, geçerli konumunu önceden tanımlanmış bir aralıkta kalıcı depolama alanına yazmalıdır. Bu şekilde, tüketici bir hatayla karşılaşırsa (örneğin, tüketici kilitlenir veya konak başarısız olursa), yeni bir örnek son kaydedilen konumdan akışı okumaya devam edebilir. Daha fazla bilgi için bkz . Olay tüketicileri.

Yinelenen iletileri işleme. Bir olay tüketicisi başarısız olursa, ileti işleme son kaydedilen denetim noktasından sürdürülür. Son denetim noktasından sonra zaten işlenmiş olan tüm iletiler yeniden işlenir. Bu nedenle, ileti işleme mantığınızın bir kez etkili olması veya uygulamanın iletileri yinelenenleri kaldırabilmesi gerekir.

Özel durumları işle.. Olay tüketicisi genellikle döngüdeki bir toplu iletileri işler. Tek bir ileti özel duruma neden olursa, bir grup iletinin tamamını kaybetmemek için bu işleme döngüsü içindeki özel durumları işlemeniz gerekir.

Teslim edilemeyen bir kuyruk kullanın. İletinin işlenmesi geçici olmayan bir hatayla sonuçlanırsa, durumu izleyebilebilmeniz için iletiyi bir teslim edilemeyen ileti kuyruğuna yerleştirin. Senaryoya bağlı olarak, iletiyi daha sonra yeniden deneyebilir, telafi işlemi uygulayabilir veya başka bir işlem gerçekleştirebilirsiniz. Event Hubs'ın yerleşik bir teslim edilemeyen ileti kuyruğu işlevine sahip olmadığını unutmayın. Azure Kuyruk Depolama veya Service Bus kullanarak teslim edilemeyen bir kuyruk uygulayabilir veya Azure İşlevleri ya da başka bir olay mekanizması kullanabilirsiniz.

Alanlar arası yedekliliği yapılandırın. Ad alanınızda alanlar arası yedeklilik etkinleştirildiğinde, Event Hubs değişiklikleri birden çok kullanılabilirlik alanı arasında otomatik olarak çoğaltır. Bir kullanılabilirlik alanı başarısız olursa yük devretme otomatik olarak gerçekleşir. Daha fazla bilgi için bkz . Kullanılabilirlik alanları.

İkincil bir Event Hubs ad alanına yük devrederek olağanüstü durum kurtarma (DR) uygulayın. Daha fazla bilgi için bkz . Azure Event Hubs Coğrafi olağanüstü durum kurtarma.

Redis için Azure Önbelleği

Alanlar arası yedekliliği yapılandırın. Önbelleğinizde alanlar arası yedeklilik etkinleştirildiğinde, Redis için Azure Cache önbelleğinizi barındıran sanal makineleri birden çok kullanılabilirlik alanına dağıtır. Alanlar arası yedeklilik, veri merkezi kesintisi durumunda yüksek kullanılabilirlik ve hataya dayanıklılık sağlar. Daha fazla bilgi için bkz. Redis için Azure Cache için bölge yedekliliğini etkinleştirme.

Coğrafi çoğaltmayı yapılandırın. Coğrafi çoğaltma, iki Premium katmanlı Redis için Azure Cache örneğini bağlamaya yönelik bir mekanizma sağlar. Birincil önbelleğe yazılan veriler ikincil salt okunur önbelleğe çoğaltılır. Daha fazla bilgi için bkz. Redis için Azure Cache için coğrafi çoğaltmayı yapılandırma

Veri kalıcılığını yapılandırın. Redis kalıcılığı Redis'de depolanan verileri kalıcı hale getirmenizi sağlar. Ayrıca anlık görüntüler alabilir ve verileri yedekleyebilirsiniz. Bu verileri donanım arızası durumunda yükleyebilirsiniz. Daha fazla bilgi için bkz. Premium katman Redis için Azure Cache için veri kalıcılığını yapılandırma

Redis için Azure Cache kalıcı depo olarak değil geçici bir veri önbelleği olarak kullanıyorsanız, bu öneriler geçerli olmayabilir.

Bilişsel Arama

Birden fazla çoğaltma sağlayın. Okuma yüksek kullanılabilirliği için en az iki çoğaltma, okuma-yazma yüksek kullanılabilirlik için üç çoğaltma kullanın.

Alanlar arası yedeklilik kullanın. Bilişsel Arama çoğaltmalarını birden çok kullanılabilirlik alanına dağıtabilirsiniz. Bu yaklaşım, veri merkezi kesintileri oluştuğunda bile hizmetinizin çalışır durumda kalmasına yardımcı olur. Daha fazla bilgi için bkz. Azure Bilişsel Arama'de güvenilirlik

Çok bölgeli dağıtımlar için dizin oluşturucuları yapılandırın. Çok bölgeli bir dağıtımınız varsa dizin oluşturmada süreklilik seçeneklerinizi göz önünde bulundurun.

• Veri kaynağı coğrafi olarak çoğaltıldıysa, genellikle her bölgesel Azure Bilişsel Arama hizmetinin her dizin oluşturucusunu kendi yerel veri kaynağı çoğaltmasına işaret etmelisiniz. Ancak, Azure SQL Veritabanı depolanan büyük veri kümeleri için bu yaklaşım önerilmez. Bunun nedeni, Azure Bilişsel Arama yalnızca birincil çoğaltmalardan, ikincil SQL Veritabanı çoğaltmalarından artımlı dizin oluşturma gerçekleştirememesidir. Bunun yerine, tüm dizin oluşturucuları birincil çoğaltmaya işaret edin. Yük devretmeden sonra, Azure Bilişsel Arama dizin oluşturucularını yeni birincil çoğaltmaya işaret edin.

• Veri kaynağı coğrafi olarak çoğaltılmazsa, birden çok dizin oluşturucuyu aynı veri kaynağına işaret edin, böylece birden çok bölgede hizmet Azure Bilişsel Arama veri kaynağından sürekli ve bağımsız olarak dizin oluşturur. Daha fazla bilgi için bkz . Azure Search performansı ve iyileştirmeyle ilgili dikkat edilmesi gerekenler.

Service Bus

Üretim iş yükleri için Premium katmanı kullanın. Service Bus Premium Mesajlaşma , öngörülebilir performans ve aktarım hızını desteklemek için ayrılmış ve ayrılmış işleme kaynakları ve bellek kapasitesi sağlar. Premium Mesajlaşma katmanı ayrıca ilk başta yalnızca premium müşterilerin kullanabileceği yeni özelliklere erişmenizi sağlar. Beklenen iş yüklerine göre mesajlaşma birimi sayısına karar vekleyebilirsiniz.

Yinelenen iletileri işleme. Bir yayımcı ileti gönderdikten hemen sonra başarısız olursa veya ağ veya sistem sorunlarıyla karşılaşırsa, iletinin teslim edildiği kaydı yanlışlıkla başarısız olabilir ve aynı iletiyi sisteme iki kez gönderebilir. Service Bus, yinelenen algılamayı etkinleştirerek bu sorunu işleyebilir. Daha fazla bilgi için bkz . Yinelenen algılama.

Özel durumları işleme. Mesajlaşma API'leri kullanıcı hatası, yapılandırma hatası veya başka bir hata oluştuğunda özel durumlar oluşturur. İstemci kodu (gönderenler ve alıcılar) kendi kodlarında bu özel durumları işlemelidir. Bu özellikle toplu işlemde önemlidir; burada özel durum işleme, ileti toplu işleminin tamamını kaybetmemek için kullanılabilir. Daha fazla bilgi için bkz . Service Bus mesajlaşma özel durumları.

İlkeyi yeniden deneyin. Service Bus, uygulamalarınız için en iyi yeniden deneme ilkesini seçmenize olanak tanır. Varsayılan ilke, en fazla 9 yeniden deneme denemesine izin vermek ve 30 saniye beklemektir, ancak bu daha fazla ayarlanabilir. Daha fazla bilgi için bkz . Yeniden deneme ilkesi – Service Bus.

Teslim edilemeyen bir kuyruk kullanın. Birden çok yeniden denemeden sonra bir ileti işlenemiyor veya herhangi bir alıcıya teslim edilemiyorsa, ileti teslim edilemeyen bir kuyruğa taşınır. Teslim edilemeyen ileti kuyruğundaki iletileri okumak, incelemek ve sorunu çözmek için bir işlem uygulayın. Senaryoya bağlı olarak, iletiyi olduğu gibi yeniden deneyebilir, değişiklik yapabilir ve yeniden deneyebilir veya iletiyi atabilirsiniz. Daha fazla bilgi için bkz . Service Bus teslim edilemeyen ileti kuyruklarına genel bakış.

Alanlar arası yedeklilik kullanın. Ad alanınızda alanlar arası yedeklilik etkinleştirildiğinde, Service Bus değişiklikleri birden çok kullanılabilirlik alanı arasında otomatik olarak çoğaltır. Bir kullanılabilirlik alanı başarısız olursa yük devretme otomatik olarak gerçekleşir. Daha fazla bilgi için bkz . Service Bus kesintilerine ve olağanüstü durumlarına karşı uygulamaları yalıtma için en iyi yöntemler.

Coğrafi Olağanüstü Durum Kurtarma'yı kullanın. Coğrafi olağanüstü durum kurtarma, olağanüstü durum nedeniyle azure bölgesinin veya veri merkezinin tamamı kullanılamaz hale gelirse veri işlemenin farklı bir bölgede veya veri merkezinde çalışmaya devam etmesini sağlar. Daha fazla bilgi için bkz . Azure Service Bus Coğrafi olağanüstü durum kurtarma.

Depolama

Alanlar arası yedekli depolama (ZRS) kullanın. Bölgesel olarak yedekli depolama (ZRS), verilerinizi, birincil bölgedeki üç Azure kullanılabilirlik alanı arasında zaman uyumlu olarak kopyalar. Kullanılabilirlik alanında kesinti yaşanırsa Azure Depolama otomatik olarak alternatif bir bölgeye yük devreder. Daha fazla bilgi için bkz. Azure Depolama yedekliliği.

Coğrafi olarak yedeklilik kullanırken okuma erişimini yapılandırın. Çok bölgeli bir mimari kullanıyorsanız, genel yedeklilik için uygun bir depolama katmanı kullanın. Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) veya okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) ile verileriniz ikincil bir bölgeye çoğaltılır. RA-GRS birincil bölgede yerel olarak yedekli depolama (LRS) kullanırken, RA-GZRS birincil bölgede alanlar arası yedekli depolama (ZRS) kullanır. Her iki yapılandırma da ikincil bölgedeki verilerinize salt okunur erişim sağlar. Birincil bölgede bir depolama kesintisi varsa, bu olasılık için tasarladıysanız uygulama ikincil bölgeden verileri okuyabilir. Daha fazla bilgi için bkz. Azure Depolama yedekliliği.

VM diskleri için yönetilen diskleri kullanın. Tek hata noktalarını önlemek için diskler birbirinden yeterince yalıtıldığından, yönetilen diskler kullanılabilirlik kümesindeki VM'ler için daha iyi güvenilirlik sağlar. Ayrıca, yönetilen diskler bir depolama hesabında oluşturulan VHD'lerin IOPS sınırlarına tabi değildir. Daha fazla bilgi için bkz . Azure'da Windows sanal makinelerinin kullanılabilirliğini yönetme.

Kuyruk depolama için başka bir bölgede bir yedekleme kuyruğu oluşturun. Kuyruk Depolama için salt okunur çoğaltmanın kullanımı sınırlıdır çünkü öğeleri kuyruğa alamıyor veya sırasını kaldıramazsınız. Bunun yerine, başka bir bölgedeki bir depolama hesabında yedekleme kuyruğu oluşturun. Azure Depolama kesintisi varsa, birincil bölge yeniden kullanılabilir duruma gelene kadar uygulama yedekleme kuyruğu kullanabilir. Bu şekilde uygulama kesinti sırasında yeni istekleri işlemeye devam edebilir.

SQL Veritabanı

Standart veya Premium katmanı kullanın. Bu katmanlar daha uzun bir belirli noktaya geri yükleme süresi (35 gün) sağlar. Daha fazla bilgi için bkz. SQL Veritabanı seçenekleri ve performansı.

SQL Veritabanı denetimini etkinleştirin. Denetim, kötü amaçlı saldırıları veya insan hatasını tanılamak için kullanılabilir. Daha fazla bilgi için bkz . SQL veritabanı denetimini kullanmaya başlama.

Etkin Coğrafi Çoğaltmayı Kullanma Farklı bir bölgede okunabilir bir ikincil oluşturmak için Etkin Coğrafi Çoğaltma kullanın. Birincil veritabanınız başarısız olursa veya yalnızca çevrimdışına alınması gerekiyorsa, ikincil veritabanına el ile yük devretme gerçekleştirin. Siz yük devredene kadar ikincil veritabanı salt okunur kalır. Daha fazla bilgi için bkz. Etkin Coğrafi Çoğaltma SQL Veritabanı.

Parçalama kullanın. Veritabanını yatay olarak bölümlendirmek için parçalama kullanmayı göz önünde bulundurun. Parçalama, hata yalıtımı sağlayabilir. Daha fazla bilgi için bkz. Azure SQL Veritabanı ile ölçeği genişletme.

İnsan hatasından kurtarmak için belirli bir noktaya geri yüklemeyi kullanın. Belirli bir noktaya geri yükleme, veritabanınızı zamanın önceki bir noktasına döndürür. Daha fazla bilgi için bkz . Otomatik veritabanı yedeklemelerini kullanarak Azure SQL veritabanını kurtarma.

Bir hizmet kesintisinden kurtarmak için coğrafi geri yükleme kullanın. Coğrafi geri yükleme, coğrafi olarak yedekli bir yedeklemeden veritabanını geri yükler. Daha fazla bilgi için bkz . Otomatik veritabanı yedeklemelerini kullanarak Azure SQL veritabanını kurtarma.

Azure Synapse Analytics

Coğrafi yedeklemeyi devre dışı bırakmayın. Varsayılan olarak, Azure Synapse Analytics olağanüstü durum kurtarma için ayrılmış SQL Havuzu'ndaki verilerinizin tam yedeğini alır. Bu özelliğin kapatılması önerilmez. Daha fazla bilgi için bkz . Coğrafi yedeklemeler.

VM'de çalışan SQL Server

Veritabanını yedekleyin. VM'lerinizi yedeklemek için zaten Azure Backup kullanıyorsanız DPM kullanarak SQL Server iş yükleri için Azure Backup'ı kullanmayı göz önünde bulundurun. Bu yaklaşımla, kuruluş için bir Yedekleme yöneticisi rolü ve VM'ler ve SQL Server için birleşik bir kurtarma yordamı vardır. Aksi takdirde SQL Server Yönetilen Yedekleme'yi Microsoft Azure'a kullanın.

Traffic Manager

El ile yeniden çalışma gerçekleştirin. Traffic Manager yük devretmesinden sonra otomatik olarak geri dönmek yerine el ile yeniden çalışma gerçekleştirin. Yeniden çalışmadan önce tüm uygulama alt sistemlerinin iyi durumda olduğunu doğrulayın. Aksi takdirde, uygulamanın veri merkezleri arasında ileri geri çevrildiği bir durum oluşturabilirsiniz. Daha fazla bilgi için bkz . Yüksek kullanılabilirlik için vm'leri birden çok bölgede çalıştırma.

Sistem durumu yoklaması uç noktası oluşturun. Uygulamanın genel durumunu bildiren özel bir uç nokta oluşturun. Bu, Traffic Manager'ın yalnızca ön ucu değil kritik bir yol başarısız olursa yük devretmesini sağlar. Herhangi bir kritik bağımlılık iyi durumda değilse veya erişilemiyorsa uç nokta bir HTTP hata kodu döndürmelidir. Ancak kritik olmayan hizmetler için hataları bildirmeyin. Aksi takdirde, sistem durumu yoklaması gerekli olmadığında yük devretmeyi tetikleyebilir ve hatalı pozitifler oluşturabilir. Daha fazla bilgi için bkz . Traffic Manager uç nokta izleme ve yük devretme.

Sanal Makineler

Üretim iş yükünü tek bir VM üzerinde çalıştırmaktan kaçının. Tek bir VM dağıtımı planlı veya plansız bakım için dayanıklı değildir. Bunun yerine, bir kullanılabilirlik kümesine veya sanal makine ölçek kümesine birden çok VM yerleştirin ve önünde yük dengeleyici bulun.

VM'yi sağlarken bir kullanılabilirlik kümesi belirtin. Şu anda, VM sağlandıktan sonra kullanılabilirlik kümesine VM eklemenin bir yolu yoktur. Mevcut kullanılabilirlik kümesine yeni bir VM eklediğinizde, VM için bir NIC oluşturduğunuzdan ve NIC'yi yük dengeleyicideki arka uç adres havuzuna eklediğinizden emin olun. Aksi takdirde yük dengeleyici ağ trafiğini bu VM'ye yönlendirmez.

Her uygulama katmanını ayrı bir Kullanılabilirlik Kümesine yerleştirin. N katmanlı bir uygulamada, farklı katmanlardaki VM'leri aynı kullanılabilirlik kümesine yerleştirmeyin. Kullanılabilirlik kümesindeki VM'ler hata etki alanları (FD) ve güncelleştirme etki alanları (UD) arasında yerleştirilir. Ancak, FD'lerin ve UD'lerin yedeklilik avantajını elde etmek için kullanılabilirlik kümesindeki her VM'nin aynı istemci isteklerini işleyebilmesi gerekir.

Azure Site Recovery kullanarak VM'leri çoğaltma. Site Recovery kullanarak Azure VM'lerini çoğalttığınızda, tüm VM diskleri zaman uyumsuz olarak hedef bölgeye sürekli olarak çoğaltılır. Kurtarma noktaları birkaç dakikada bir oluşturulur. Bu size dakika sırasına göre bir Kurtarma Noktası Hedefi (RPO) verir. Üretim uygulamasını veya devam eden çoğaltmayı etkilemeden olağanüstü durum kurtarma tatbikatlarını istediğiniz kadar gerçekleştirebilirsiniz. Daha fazla bilgi için bkz . Azure'da olağanüstü durum kurtarma tatbikatı çalıştırma.

Performans gereksinimlerine göre doğru VM boyutunu seçin. Mevcut bir iş yükünü Azure'a taşırken, şirket içi sunucularınıza en yakın vm boyutuyla başlayın. Ardından gerçek iş yükünüzün performansını CPU, bellek ve disk IOPS ile ölçün ve gerekirse boyutu ayarlayın. Bu, uygulamanın bulut ortamında beklendiği gibi davranmasını sağlamaya yardımcı olur. Ayrıca, birden çok NIC'ye ihtiyacınız varsa, her boyut için NIC sınırına dikkat edin.

VHD'ler için yönetilen diskleri kullanın. Tek hata noktalarını önlemek için diskler birbirinden yeterince yalıtıldığından, yönetilen diskler kullanılabilirlik kümesindeki VM'ler için daha iyi güvenilirlik sağlar. Ayrıca, yönetilen diskler bir depolama hesabında oluşturulan VHD'lerin IOPS sınırlarına tabi değildir. Daha fazla bilgi için bkz . Azure'da Windows sanal makinelerinin kullanılabilirliğini yönetme.

Uygulamaları işletim sistemi diskinde değil veri diskinde yükleyin. Aksi takdirde, disk boyutu sınırına ulaşabilirsiniz.

VM'leri yedeklemek için Azure Backup'ı kullanın. Yedeklemeler yanlışlıkla veri kaybına karşı koruma sağlar. Daha fazla bilgi için bkz . Kurtarma Hizmetleri kasasıyla Azure VM'lerini koruma.

Tanılama günlüklerini etkinleştirin. Temel sistem durumu ölçümlerini, altyapı günlüklerini ve önyükleme tanılamalarını ekleyin. Önyükleme tanılaması, VM'niz önyükleme yapılamayan bir duruma geçerse önyükleme hatasını tanılamanıza yardımcı olabilir. Daha fazla bilgi için bkz . Azure Tanılama Günlüklerine Genel Bakış.

Azure İzleyici'yi yapılandırma. Konuk işletim sistemi ve içinde çalışan iş yükleri dahil olmak üzere Azure Sanal Makineler izleme verilerini toplayın ve analiz edin. Bkz. Azure İzleyici ve Hızlı Başlangıç: Azure İzleyici.

Sanal Ağ

Genel IP adreslerine izin vermek veya bunları engellemek için alt ağa bir ağ güvenlik grubu ekleyin. Kötü amaçlı kullanıcıların erişimini engelleyin veya yalnızca uygulamaya erişim ayrıcalığına sahip kullanıcıların erişimine izin verin.

Özel durum araştırması oluşturun. Yük Dengeleyici Sistem Durumu Yoklamaları HTTP veya TCP'yi test edebilir. VM bir HTTP sunucusu çalıştırıyorsa, HTTP yoklaması tcp yoklamasından daha iyi bir sistem durumu göstergesidir. HTTP araştırması için, tüm kritik bağımlılıklar dahil olmak üzere uygulamanın genel durumunu bildiren özel bir uç nokta kullanın. Daha fazla bilgi için bkz . Azure Load Balancer'a genel bakış.

Sistem durumu araştırmasını engellemeyin. Load Balancer Sistem Durumu yoklaması bilinen bir IP adresinden (168.63.129.16) gönderilir. Herhangi bir güvenlik duvarı ilkesinde veya ağ güvenlik grubu kurallarında bu IP'ye gelen veya bu IP'den gelen trafiği engellemeyin. Sistem durumu yoklamasını engellemek yük dengeleyicinin VM'yi döndürmeden kaldırmasına neden olabilir.

Load Balancer günlüğünü etkinleştirin. Günlükler, başarısız yoklama yanıtları nedeniyle arka uçta kaç VM'nin ağ trafiği almadığını gösterir. Daha fazla bilgi için bkz . Azure Load Balancer için Log Analytics.