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 hizmetleri için dayanıklılıkla ilgili dikkat edilmesi gerekenleri 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ını kullanın. Bu katmanlar hazırlama yuvalarını ve otomatik yedeklemeleri destekler. Daha fazla bilgi için bkz. Azure App Service planlara 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 App Service'de web uygulamalarını yapılandırma.
Üretim ve test için ayrı App Service planları oluşturun. Üretim dağıtımınızda test için yuva 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ıtmış olursunuz.
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 uygulamalara ayırmayı göz önünde bulundurun. Bu tasarım, çözümü iş yüküne göre ayrıştırmayı 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.
Azure SQL veritabanlarını yedeklemek için App Service yedekleme özelliğini kullanmaktan kaçının. Bunun yerine otomatik yedeklemeleri SQL Veritabanı kullanın. App Service yedekleme, veritabanını bir SQL BACPAC dosyasına aktarır ve bu da DTU'lara mal olur.
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 tüm örneklerin üretime değiştirilmeden önce ı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 App Service'da 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 App Service'de web uygulamaları için tanılama günlüğünü etkinleştirme
Blob depolamada günlüğe kaydetme. 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ı izleme. Yük altında 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ü 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 Load Balancer Temel'in sağlamadığı bir güvenilirlik boyutu sağlar; kullanılabilirlik alanları ve bölge dayanıklılığı. Bu, bir bölge kapandığı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ğlama Azure LB'yi 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 LB'yi Sanal Makine Ölçek Kümeleri ile eşleştirmek isteyebilirsiniz.
Giden kurallarını kullanma Giden kuralları, 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 Load Balancer veya sanal ağ NAT ile herhangi bir alt ağ dağıtımını bağlamanızı öneririz.
Application Gateway
En az iki örnek sağlayın. Application Gateway 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. SLA'ya hak kazanmak için iki veya daha fazla orta veya daha büyük örnek sağlamalısınız.
Azure Cosmos DB
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ı bir yazma bölgesine ve birden çok okuma bölgesine sahip 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ı depolamaya 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 akışı son kaydedilen konumdan okumaya devam edebilir. Daha fazla bilgi için bkz . Olay tüketicileri.
Yinelenen iletileri işleme. 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ş tüm iletiler yeniden işlenir. Bu nedenle, ileti işleme mantığınız bir kez etkili olmalı veya uygulamanın iletileri yinelenenleri kaldırabilmesi gerekir.
Özel durumları işle.. Olay tüketicisi genellikle döngüdeki bir dizi iletiyi işler. Tek bir ileti özel duruma neden olursa, iletilerin 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 herhangi bir yerleşik teslim edilemeyen ileti kuyruğu işlevine sahip olmadığını unutmayın. Teslim edilemeyen bir kuyruk uygulamak için Azure Kuyruk Depolama veya Service Bus kullanabilir ya da Azure İşlevleri ya da başka bir olay mekanizması kullanabilirsiniz.
İkincil bir Event Hubs ad alanına yük devrederek olağanüstü durum kurtarma uygulayın. Daha fazla bilgi için bkz. Coğrafi olağanüstü durum kurtarma Azure Event Hubs.
Redis için Azure Cache
Coğrafi çoğaltmayı yapılandırın. Coğrafi çoğaltma, iki Premium katmanlı Redis için Azure Cache örneğini bağlamak için bir mekanizma sağlar. Birincil önbelleğe yazılan veriler ikincil bir 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ırma. 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 hatası durumunda yükleyebilirsiniz. Daha fazla bilgi için bkz. Premium katmanlı bir Redis için Azure Cache için veri kalıcılığını yapılandırma
Redis için Azure Cache kalıcı bir depo olarak değil geçici bir veri önbelleği olarak kullanıyorsanız, bu öneriler geçerli olmayabilir.
Arayın
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ılabilirliği için üç ç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şturmada süreklilik seçeneklerinizi göz önünde bulundurun.
Veri kaynağı coğrafi olarak çoğaltıldıysa, genellikle her bölgesel Azure Arama hizmeti her dizin oluşturucusunu kendi yerel veri kaynağı çoğaltmasına işaret etmelisiniz. Ancak, Azure SQL Veritabanında depolanan büyük veri kümeleri için bu yaklaşım önerilmez. Bunun nedeni, Azure Search'in ikincil SQL Veritabanı çoğaltmalarından artımlı dizin oluşturma gerçekleştirememesidir; yalnızca birincil çoğaltmalardan. Bunun yerine, tüm dizin oluşturucuları birincil çoğaltmaya işaret edin. Yük devretme işleminden sonra Azure Search dizin oluşturucularını yeni birincil çoğaltmanın üzerine gelin.
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 yer alan Azure Search hizmetleri sürekli olarak ve bağımsız olarak veri kaynağından dizin oluşturur. Daha fazla bilgi için bkz. Azure Search performansı ve iyileştirmesi ile ilgili dikkat edilmesi gerekenler.
Service Bus
Üretim iş yükleri için Premium katmanını 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, yanlışlıkla iletinin teslim edildiği kaydı 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, bir toplu iletinin 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şlenemiyorsa veya herhangi bir alıcıya teslim edilemiyorsa, ileti teslim edilemeyen bir ileti kuyruğuna 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ış.
Geo-Disaster Kurtarma'ya gidin. 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. Coğrafi olağanüstü durum kurtarma Azure Service Bus.
Depolama
Depolama hesabınızı okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) veya okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) için yapılandırın. RA-GRS veya 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 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ılmış olduğundan, yönetilen diskler kullanılabilirlik kümesindeki VM'ler için daha yüksek 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 kuyruğa alamıyorsunuz. Bunun yerine, başka bir bölgedeki depolama hesabında bir 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ını 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ğ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ışı olması gerekiyorsa, ikincil veritabanına el ile yük devretme gerçekleştirin. 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ükleme 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.
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ırakma. Synapse Analytics, olağanüstü durum kurtarma için varsayılan olarak her 24 saatte bir 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ı çoğaltma. Veritabanını çoğaltmak için SQL Server AlwaysOn kullanılabilirlik gruplarını 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'lerini çalıştırma
Veritabanını yedekleyin. VM'lerinizi yedeklemek için zaten Azure Backup kullanıyorsanız DPM kullanan 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 birden çok bölgede VM ç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, herhangi bir kritik yol başarısız olursa yük devretme gerçekleştirmesini sağlar. Kritik bir bağımlılık iyi durumda değilse veya ulaşılamıyorsa uç nokta bir HTTP hata kodu döndürmelidir. Ancak kritik olmayan hizmetlerle ilgili 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'de çalıştırmaktan kaçının. Tek bir VM dağıtımı planlı veya plansız bakıma dayanıklı değildir. Bunun yerine, birden çok VM'yi bir kullanılabilirlik kümesine veya sanal makine ölçek kümesine 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ından yararlanmak 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 cinsinden 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ızla en yakın olan VM boyutuyla başlayın. Ardından cpu, bellek ve disk IOPS ile ilgili gerçek iş yükünüzün performansını ö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 diskler kullanın. Tek hata noktalarını önlemek için diskler birbirinden yeterince yalıtılmış olduğundan, yönetilen diskler kullanılabilirlik kümesindeki VM'ler için daha yüksek 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 bir 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ı dahil edin. Önyükleme tanılaması, VM'niz önyükleme yapılamaz 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 de dahil olmak üzere Azure sanal makinelerinden 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ığı olan kullanıcıların erişimine izin verin.
Özel durum araştırması oluşturun. Load Balancer Durum Yoklamaları HTTP veya TCP'i test edebilir. VM bir HTTP sunucusu çalıştırıyorsa, HTTP yoklaması TCP yoklamasından daha iyi bir sistem durumu göstergesidir. HTTP yoklaması 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 genel bakış.
Sistem durumu araştırmasını engellemeyin. Load Balancer 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 araştırmasını engellemek yük dengeleyicinin VM'yi döndürmeden kaldırmasına neden olabilir.
Load Balancer günlüğe kaydetmeyi 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.