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 kendi özel başarısızlık modları vardır ve uygulamanızı tasarlarken ve uygularken göz önünde bulundurmanız gerekir. Belirli Azure hizmetlerine yönelik dayanıklılık konularını gözden geçirmek için bu denetim listesini kullanın. Esnek uygulamalar tasarlama hakkında daha fazla bilgi için bkz. güvenilir Azure uygulamaları tasarlama.
App Service
standart veya Premium katmanını kullanın. Bu katmanlar, hazırlama yuvalarını ve otomatik yedeklemeleri destekler. Daha fazla bilgi için bkz. Azure App Service planlar ayrıntılı genel bakış
Ölçeklendirmeden veya azaltılabilirsiniz. Bunun yerine, tipik yük altında performans gereksinimlerinizi karşılayan bir katman ve örnek boyutu seçin ve ardından, trafik hacminde değişiklikleri işlemek için örnekleri ölçeklendirin . Ölçeği artırma ve azaltma, bir 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. Bu ayarları, daha güvenilir olan bir otomatik dağıtım/güncelleştirme sürecinin bir parçası olarak uygulayabilmeniz için Kaynak Yöneticisi şablonlarınızdaki veya PowerShell kullanarak tanımlayın. Daha fazla bilgi için bkz. Azure App Service 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ı içindeki tüm uygulamalar aynı sanal makine örneklerini paylaşır. Üretim ve test dağıtımlarını aynı plana yerleştirirseniz, ü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 API 'Lerinden ayrı Web uygulamaları ayırın. Çözümünüz hem Web ön ucu hem de bir Web API 'SI içeriyorsa, bunları ayrı App Service uygulamalarına ayırmayı düşünün. Bu tasarım çözümü iş yüküne göre ayırmayı kolaylaştırır. Web uygulamasını ve API 'YI ayrı App Service planlarda çalıştırabilirsiniz, bu nedenle bağımsız olarak ölçeklendirilebilirler. İlk olarak bu ölçeklenebilirlik düzeyine ihtiyacınız yoksa, uygulamaları aynı plana dağıtabilir ve gerekirse daha sonra bunları ayrı planlara taşıyabilirsiniz.
Azure SQL veritabanlarını yedeklemek için App Service yedekleme özelliğini kullanmaktan kaçının. bunun yerine, SQL Veritabanı otomatikleştirilmiş yedeklemelerikullanın. App Service yedekleme, veritabanını bir SQL bacpac dosyasına dışarı aktarır ve bu da dtu 'ları ücretlerden çıkartı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 üretim ortamına takas etmeden önce dağıtımı doğrulayın. Bu, üretimde kötü bir güncelleştirme olasılığını azaltır. Ayrıca, tüm örneklerin üretime değiştirilmeden önce de çarpımasını sağlar. Birçok uygulamanın önemli bir ısınma ve soğuk başlangıç zamanı vardır. Daha fazla bilgi için bkz. Azure App Service Web Apps için hazırlama ortamlarını ayarlama.
Bilinen son iyi (LKG) dağıtımı barındıracak bir dağıtım yuvası oluşturun. Üretime bir güncelleştirme dağıttığınızda, önceki üretim dağıtımını LKG yuvasına taşıyın. Bu, hatalı bir dağıtımı geri almayı kolaylaştırır. Daha sonra bir sorun keşfettiğiniz takdirde, hızlı bir şekilde LKG sürümüne döndürebilirsiniz. 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 App Service Web Apps için tanılama günlüğünü etkinleştirme
BLOB depolama alanına 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ük kaydının uygulama performansını azaltmasını önlemeye yardımcı olur.
Performansı izleyin. uygulama performansını ve yük altındaki davranışı izlemek için yeni relik veya Application Insights gibi bir performans izleme hizmeti kullanın. Performans izleme, uygulamayla ilgili gerçek zamanlı öngörüler sağlar. Sorunları tanılamanıza ve hataların kök neden analizini gerçekleştirmenize olanak sağlar.
Azure Load Balancer
Standart SKU seçin Standart Load Balancer, temel tarafından kullanılabilirlik alanları ve bölge dayanıklılığı açısından olmayan bir güvenilirlik boyutu sağlar. Bu, bir bölgenin bir arada kaldığında, bölgesel olarak yedekli Standart Load Balancer etkilenmeyeceği anlamına gelir. Bu, dağıtımlarınızın bölge içindeki bölge başarısızlıklarını kapsamasını sağlar. Ayrıca, Standart Load Balancer, uygulamanızın bölge hatalarından etkilenmemesini sağlamak için genel yük dengelemeyi da destekler.
En az iki örnek sağlayın Azure LB ' i arka uçta en az iki örnek ile dağıtın. Tek bir örnek tek bir hata noktası oluşmasına neden olabilir. Ölçek oluşturmak için, sanal makine ölçek kümeleri ile LB eşleştirmek isteyebilirsiniz.
Giden kuralları kullanma Giden kuralları, SNAT bağlantı arızalarının bir sonucu olarak bağlantı hatalarıyla birlikte çıkmış olduğunuzdan emin olun. Giden bağlantı hakkında daha fazla bilgi edinin. Giden kuralları, küçük ve orta ölçekli dağıtımlar için çözümü iyileştirmenize yardımcı olur. üretim iş yükleri için, VNET NATile standart Load Balancer veya herhangi bir alt ağ dağıtımı yapmanızı öneririz.
Application Gateway
En az iki örnek sağlayın. Application Gateway en az iki örnek ile dağıtın. Tek bir örnek, tek bir hata noktasıdır. Artıklık ve ölçeklenebilirlik için iki veya daha fazla örnek kullanın. SLA'ya hak kazanmak için, iki veya daha fazla orta ya da daha büyük örnek sağlamalısınız.
Cosmos DB
Veritabanını bölgeler arasında çoğaltın. Cosmos DB, herhangi bir sayıda Azure bölgesini Cosmos DB veritabanı hesabıyla ilişkilendirmenize olanak tanır. bir Cosmos DB veritabanında bir yazma bölgesi ve birden çok okuma bölgesi bulunabilir. Yazma bölgesinde bir hata varsa, başka bir çoğaltmadan okuma yapabilirsiniz. Istemci SDK bunu otomatik olarak işler. Ayrıca, yazma bölgesinin yükünü başka bir bölgeye devreder. Daha fazla bilgi için bkz. Azure Cosmos DB ile verileri küresel ölçekte dağıtma.
Event Hubs
Kontrol noktaları kullanın. Bir olay tüketicisinin geçerli konumunu, önceden tanımlanmış bazı aralıklarla kalıcı depolamaya yazması gerekir. Bu şekilde, tüketici bir hata yaşıyorsa (örneğin, tüketici kilitlenirse veya ana bilgisayar başarısız olursa), yeni bir örnek akışı son kaydedilen konumdan okumayı sürdürür. Daha fazla bilgi için bkz. olay tüketicileri.
Yinelenen iletileri işleyin. Bir olay tüketicisi başarısız olursa, ileti işleme son kayıt 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 ıdempotent olması veya uygulamanın iletileri yinekurabilmesi gerekir.
Özel durumları işle.. Olay tüketicisi genellikle bir döngüdeki bir ileti toplu işini işler. Tek bir ileti bir özel duruma neden oluyorsa, tüm ileti toplu işleminin kaybedilmesini önlemek için bu işleme döngüsünde özel durumları işlemeniz gerekir.
Atılacak ileti sırası kullanın. Bir iletiyi işlemek geçici olmayan bir hata ile sonuçlanırsa, durumu izleyebilmek için iletiyi atılacak ileti kuyruğuna koyun. Senaryoya bağlı olarak, daha sonra iletiyi yeniden deneyebilir, telafi işlemi uygulayabilir veya başka bir eylem gerçekleştirebilirsiniz. Event Hubs yerleşik bir atılacak ileti sırası işlevselliğine sahip olmadığını unutmayın. bir atılacak ileti sırası uygulamak veya azure işlevlerini ya da başka bir olay mekanizmasını kullanmak için azure kuyruğu Depolama veya Service Bus kullanabilirsiniz.
İkincil bir Event Hubs ad alanına yük devreterek olağanüstü durum kurtarma uygulayın. Daha fazla bilgi için bkz. Azure Event Hubs coğrafi olağanüstü durum kurtarma.
Redis için Azure Cache
Coğrafi çoğaltmayı yapılandırma. coğrafi çoğaltma, redsıs örnekleri için iki Premium katmanlı Azure önbelleğinin bağlanmasına yönelik bir mekanizma sağlar. Birincil önbelleğe yazılan veriler, ikincil bir salt okuma önbelleğine çoğaltılır. Daha fazla bilgi için bkz. redsıs Için Azure önbelleği için Coğrafi çoğaltmayı yapılandırma
Veri kalıcılığını yapılandırın. Redsıs kalıcılığı, redin içinde depolanan verileri kalıcı hale getirebilmeniz için izin verir. Ayrıca, anlık görüntüler alabilir ve verileri yedekleyebilir ve bu da donanım arızası durumunda yükleyebilirsiniz. daha fazla bilgi için bkz. redsıs için Premium katmanı Azure önbelleği için veri kalıcılığını yapılandırma
Redsıs için Azure önbellek 'yi kalıcı bir depo olarak değil, geçici bir veri önbelleği olarak kullanıyorsanız, bu öneriler uygulanmayabilir.
Arayın
Birden fazla çoğaltma sağlayın. Okuma/yazma yüksek kullanılabilirlik için en az iki çoğaltma kullanın.
Ç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şturma işleminin sürekliliği için seçeneklerinizi göz önünde bulundurun.
Veri kaynağı coğrafi olarak çoğaltılırsa, her bölgesel Azure Search hizmetinin her bir dizin oluşturucuyu yerel veri kaynağı çoğaltmasına işaret etmelisiniz. ancak, bu yaklaşım Azure SQL Veritabanı depolanan büyük veri kümeleri için önerilmez. bunun nedeni, Azure Search ikincil SQL Veritabanı çoğaltmalarından yalnızca birincil çoğaltmalardan artımlı dizin oluşturmamasının nedenidir. Bunun yerine, tüm dizin oluşturucularının birincil çoğaltmaya işaret edin. Yük devretmenin ardından, yeni birincil çoğaltmadaki Azure Search dizin oluşturucularının üzerine gelin.
Veri kaynağı coğrafi olarak çoğaltılmamışsa, aynı veri kaynağında birden çok Dizin Oluşturucu ve birden çok bölgedeki hizmetlerin veri kaynağından sürekli olarak ve bağımsız bir dizin Azure Search. Daha fazla bilgi için bkz. Azure Search performans ve iyileştirme konuları.
Service Bus
üretim iş yükleri için Premium katmanını kullanın. Service Bus Premium mesajlaşma , öngörülebilir performansı ve üretilen işi desteklemek için adanmış ve ayrılmış işleme kaynakları ve bellek kapasitesi sağlar. Premium mesajlaşma katmanı, yalnızca ilk başta Premium müşterilere sunulan yeni özelliklere erişmenizi sağlar. Beklenen iş yüklerini temel alan Mesajlaşma Birimi sayısına karar verebilirsiniz.
Yinelenen Iletileri işleyin. Bir yayımcı bir ileti gönderdikten hemen sonra başarısız olursa ya da ağ ya da sistem sorunları yaşıyorsa, iletinin teslim edildiğini yanlışlıkla kaydedemeyebilir ve aynı iletiyi sisteme iki kez gönderebilir. Service Bus, yinelenen saptamayı etkinleştirerek bu sorunu işleyebilir. Daha fazla bilgi için bkz. yinelenen algılama.
Özel durumları işleyin. Mesajlaşma API 'Leri, bir kullanıcı hatası, yapılandırma hatası veya başka bir hata oluştuğunda özel durum oluşturur. İstemci kodu (Gönderenler ve alıcılar) kendi kodlarında bu özel durumları işlemelidir. Bu özellikle toplu işleme için önemlidir, burada özel durum işleme, tüm ileti toplu iş kaybını önlemek için kullanılabilir. daha fazla bilgi için bkz. mesajlaşma özel durumları Service Bus.
Yeniden deneme ilkesi. Service Bus, uygulamalarınız için en iyi yeniden deneme ilkesini seçmenizi sağlar. Varsayılan ilke, 9 en fazla yeniden deneme denemesine izin vermek ve 30 saniye bekler, bu da daha fazla ayarlanabilir. Daha fazla bilgi için bkz. yeniden deneme ilkesi – Service Bus.
Atılacak ileti sırası kullanın. Bir ileti birden çok yeniden denemeden sonra işlenmezse veya herhangi bir alıcıya teslim edilemez, atılacak bir sıraya taşınır. Geçerliliği kalmamış ileti sırasından iletileri okumak için bir işlem uygulayın, onları inceleyin ve sorunu düzeltin. Senaryoya bağlı olarak, iletiyi olduğu gibi yeniden deneyebilir, değişiklikler yapabilir ve yeniden deneyebilir veya iletiyi atabilirsiniz. daha fazla bilgi için bkz. Service Bus atılacak ileti sıralarına genel bakış.
Geo-Disaster kurtarma kullanın. Coğrafi olağanüstü durum kurtarma, bir Azure bölgesinin veya veri merkezinin tamamı bir olağanüstü durum nedeniyle 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
Uygulama verileri için Okuma Erişimli Coğrafi olarak yedekli depolama (RA-GRS) kullanın. RA-GRS depolaması, verileri bir ikincil bölgeye çoğaltır ve ikincil bölgeden salt okuma erişimi sağlar. Birincil bölgede bir depolama kesintisi varsa, uygulama, verileri ikincil bölgeden okuyabilir. daha fazla bilgi için bkz. Azure Depolama çoğaltma.
VM diskleri için yönetilen diskleri kullanın.Yönetilen diskler , bir kullanılabilirlik kümesindeki VM 'ler için daha iyi güvenilirlik sağlar, çünkü diskler birbirinden yeterince yalıtılmış olduğundan, tek hata noktalarından kaçının. Ayrıca, yönetilen diskler, depolama hesabında oluşturulan VHD 'lerin ıOPS sınırlarına tabi değildir. daha fazla bilgi için bkz. Azure 'da Windows sanal makinelerin kullanılabilirliğini yönetme.
Kuyruk depolaması için, başka bir bölgede bir yedekleme kuyruğu oluşturun. Kuyruk depolaması için, öğeleri sıralamadığınızdan veya sıradan sıradan yalnızca bir salt okuma çoğaltması sınırlıdır. Bunun yerine, başka bir bölgedeki bir depolama hesabında yedekleme kuyruğu oluşturun. Depolama kesintisi varsa, birincil bölge yeniden kullanılabilir olana kadar uygulama yedekleme kuyruğunu kullanabilir. Bu şekilde, uygulama yeni istekleri yine de işleyebilir.
SQL Veritabanı
standart veya Premium katmanını kullanın. Bu katmanlar, daha uzun bir zaman noktası 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ğaltma kullanma Farklı bir bölgede okunabilir bir ikincil oluşturmak için etkin Geo-Replication 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. Yük devretmek için ikincil veritabanı salt okunurdur. daha fazla bilgi için bkz. etkin coğrafi çoğaltma SQL Veritabanı.
Parçalama kullanın. Veritabanını yatay olarak bölümlemek için parçalama kullanmayı düşünün. Parçalama, hata yalıtımı sağlayabilir. daha fazla bilgi için bkz. Azure SQL Veritabanı genişletme.
İnsan hatasından kurtarmak için zaman noktası geri yükleme kullanın. Zaman içinde geri yükleme, veritabanınızı önceki bir zaman noktasına geri döndürür. daha fazla bilgi için bkz. otomatik veritabanı yedeklemeleri kullanarak Azure SQL veritabanını kurtarma.
Bir hizmet kesintisinden kurtarmak için coğrafi geri yüklemeyi kullanın. Coğrafi geri yükleme bir veritabanını coğrafi olarak yedekli bir yedekten geri yükler. daha fazla bilgi için bkz. otomatik veritabanı yedeklemeleri kullanarak Azure SQL veritabanını kurtarma.
Azure Synapse Analytics
Coğrafi yedeklemeyi devre dışı bırakın. Varsayılan olarak, SYNAPSE Analytics olağanüstü durum kurtarma için her 24 saatte bir tam yedekleme gerçekleştirir. Bu özelliğin kapatılması önerilmez. Daha fazla bilgi için bkz. coğrafi yedeklemeler.
bir VM 'de çalışan SQL Server
Veritabanını çoğaltın. veritabanını çoğaltmak için SQL Server Always On kullanılabilirlik grupları kullanın. bir SQL Server örneği başarısız olursa yüksek kullanılabilirlik sağlar. daha fazla bilgi için bkz. N katmanlı bir uygulama için Windows vm 'leri çalıştırma
Veritabanını yedekleyin. sanal makinelerinizi yedeklemek için zaten Azure Backup kullanıyorsanız, DPM kullanarak SQL Server iş yükleri için Azure Backupkullanmayı göz önünde bulundurun. Bu yaklaşımla, kuruluş için bir yedekleme Yöneticisi rolü ve sanal makineler ve SQL Server birleştirilmiş bir kurtarma yordamı vardır. aksi takdirde, Microsoft Azure için SQL Server yönetilen yedeklemekullanın.
Traffic Manager
El ile yeniden çalışma gerçekleştirin. Traffic Manager yük devretmeden sonra otomatik olarak yeniden çalışma işlemi gerçekleştirin. Yeniden başarısız olmadan önce tüm uygulama alt sistemlerinin sağlıklı olduğunu doğrulayın. Aksi takdirde, uygulamanın veri merkezleri arasında geri ve ileri tersine geri aldığı bir durum oluşturabilirsiniz. Daha fazla bilgi için bkz. yüksek kullanılabilirlik için birden fazla bölgede VM çalıştırma.
Bir sistem durumu araştırma uç noktası oluşturun. Uygulamanın genel sistem durumu hakkında rapor veren özel bir uç nokta oluşturun. bu, yalnızca ön uç değil, herhangi bir kritik yol başarısız olursa Traffic Manager yük devredebilmesini sağlar. Kritik bir bağımlılığın sağlıksız veya ulaşılamaz olması durumunda uç nokta bir HTTP hata kodu döndürmelidir. Ancak kritik olmayan hizmetler için hata bildirmeyin, ancak. Aksi takdirde, sistem durumu araştırması gerekli olmadığında yük devretmeyi tetikleyip hatalı pozitif sonuçlar oluşturuyor olabilir. daha fazla bilgi için bkz. Traffic Manager uç nokta izleme ve yük devretme.
Sanal Makineler
Tek bir VM 'de üretim iş yükünü çalıştırmaktan kaçının. Tek bir VM dağıtımı planlı veya planlanmamış bakımda dayanıklı değildir. Bunun yerine, bir kullanılabilirlik kümesinde veya sanal makine ölçek kümesindebirden çok VM 'yi ön bir yük dengeleyiciye yerleştirin.
VM 'yi sağladığınızda bir kullanılabilirlik kümesi belirtin. Şu anda VM sağlandıktan sonra bir kullanılabilirlik kümesine VM eklemenin bir yolu yoktur. Mevcut bir kullanılabilirlik kümesine yeni bir sanal makine eklediğinizde, sanal makine için bir NIC oluşturun ve NIC 'yi yük dengeleyicideki arka uç adres havuzuna ekleyin. 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ı katmanlardan VM 'Leri aynı Kullanılabilirlik kümesine yerleştirmeyin. Bir kullanılabilirlik kümesindeki VM 'Ler hata etki alanları (FDs) ve güncelleştirme etki alanları (UD) üzerinden yerleştirilir. Ancak, FDs ve UDs 'nin artıklık avantajlarından yararlanmak için, kullanılabilirlik kümesindeki her VM aynı istemci isteklerini işleyebilmelidir.
Azure Site Recovery kullanarak VM 'Leri çoğaltın. Site Recoverykullanarak Azure VM 'leri çoğalttığınızda, tüm VM diskleri sürekli olarak hedef bölgeye çoğaltılır. Kurtarma noktaları birkaç dakikada bir oluşturulur. Bu, dakika düzeninde bir kurtarma noktası hedefi (RPO) sağlar. Üretim uygulamasını veya devam eden Çoğaltmayı etkilemeden, olağanüstü durum kurtarma detaylarını dilediğiniz kadar istediğiniz zaman gerçekleştirebilirsiniz. Daha fazla bilgi için bkz. Azure 'da olağanüstü durum kurtarma ayrıntısı ç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ız için en yakın eşleşen VM boyutuyla başlayın. Ardından, gerçek iş yükünüzün performansını CPU, bellek ve disk ıOPS açısından ölçerek, gerekirse boyutunu ayarlayın. Bu, uygulamanın bir bulut ortamında beklendiği gibi davrandığından emin olmanıza yardımcı olur. Ayrıca, birden çok NIC gerekiyorsa, her boyut için NIC sınırını unutmayın.
VHD 'ler için yönetilen diskleri kullanın.Yönetilen diskler , bir kullanılabilirlik kümesindeki VM 'ler için daha iyi güvenilirlik sağlar, çünkü diskler birbirinden yeterince yalıtılmış olduğundan, tek hata noktalarından kaçının. Ayrıca, yönetilen diskler, depolama hesabında oluşturulan VHD 'lerin ıOPS sınırlarına tabi değildir. daha fazla bilgi için bkz. Azure 'da Windows sanal makinelerin kullanılabilirliğini yönetme.
Uygulamaları, işletim sistemi diskine değil, bir veri diskine yükler. Aksi takdirde, disk boyut sınırına ulaşılamayabilir.
VM 'Leri yedeklemek için Azure Backup kullanın. Yedeklemeler, yanlışlıkla veri kaybına karşı koruma altına alın. Daha fazla bilgi için bkz. Azure VM 'lerini bir kurtarma hizmetleri kasasıyla koruma.
Tanılama günlüklerini etkinleştirin. Temel sistem durumu ölçümlerini, altyapı günlüklerini ve önyükleme tanılamayıekleyin. Önyükleme Tanılaması, VM 'niz önyüklenebilir olmayan bir duruma alırsa ö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 Izleyicisini yapılandırın. Azure sanal makineler 'den, Konuk işletim sistemi ve içinde çalışan iş yükleri dahil olmak üzere izleme verilerini toplayın ve çözümleyin, bkz. Azure izleyici ve hızlı başlangıç: Azure izleyici.
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ılardan erişimi engelleyin veya yalnızca uygulamaya erişim ayrıcalığına sahip olan kullanıcılardan erişime izin verin.
Özel bir sistem durumu araştırması oluşturun. Load Balancer sistem durumu araştırmaları, HTTP veya TCP 'yi test edebilir. Bir VM bir HTTP sunucusu çalıştırıyorsa, HTTP araştırması bir TCP araştırmasından daha iyi bir sistem durumu göstergesidir. Bir HTTP araştırması için, tüm kritik bağımlılıklar dahil olmak üzere uygulamanın genel durumunu raporlayan özel bir uç nokta kullanın. daha fazla bilgi için bkz. Azure Load Balancer genel bakış.
Sistem durumu araştırmasını engellemez. Load Balancer sistem durumu araştırması, bilinen bir IP adresinden gönderilir, 168.63.129.16. Herhangi bir güvenlik duvarı ilkelerinde veya ağ güvenlik grubu kurallarında bu IP 'ye giden trafiği engellemez. Sistem durumu araştırmasının engellenmesi, yük dengeleyicinin VM 'yi dönüşten kaldırmasına neden olur.
Load Balancer günlüğe kaydetmeyi etkinleştirin. Günlükler, başarısız araştırma yanıtları nedeniyle arka uçtaki kaç VM 'nin ağ trafiği almadığını gösterir. Daha fazla bilgi için bkz. Azure Load Balancer Için Log Analytics.