Azure güvenilirlik belgeleri

  • Makale

Güvenilirlik iki ilkeden oluşur: dayanıklılık ve kullanılabilirlik. Dayanıklılığın amacı hatalardan kaçınmak ve yine de oluşursa uygulamanızı tam olarak çalışır duruma döndürmektir. Kullanılabilirlik amacı, uygulamanıza veya iş yükünüz için tutarlı erişim sağlamaktır. Uygulama gereksinimlerinize göre proaktif güvenilirlik planlamanız önemlidir.

Azure, iş gereksinimlerinize göre kullanabileceğiniz ve yönetebileceğiniz yerleşik güvenilirlik hizmetleri içerir. Tek bir donanım düğümü hatası, raf düzeyinde hata, veri merkezi kesintisi veya büyük ölçekli bölgesel bir kesinti olsun, Azure güvenilirliği artıran çözümler sunar. Örneğin kullanılabilirlik kümeleri, Azure'da dağıtılan sanal makinelerin bir kümedeki birden çok yalıtılmış donanım düğümüne dağıtılmasını sağlar. Kullanılabilirlik alanları, müşterilerin uygulamalarını ve verilerini bir bölgedeki birden çok fiziksel konumdaki veri merkezi hatalarından korur. Bölgeler ve kullanılabilirlik alanları , uygulama tasarımı ve dayanıklılık stratejinizin merkezinde yer alır ve bu makalenin devamında daha ayrıntılı olarak ele alınmaktadır.

Azure güvenilirlik belgeleri, Azure hizmetleri için güvenilirlik kılavuzu sunar. Bu kılavuz kullanılabilirlik alanı desteği, olağanüstü durum kurtarma kılavuzu ve hizmetlerin kullanılabilirliği hakkındaki bilgileri içerir.

Kullanılabilirlik alanları, olağanüstü durum kurtarma veya yüksek kullanılabilirlik gibi hizmete özgü ayrıntılı güvenilirlik kılavuzu için bkz . Azure hizmetine özgü güvenilirlik kılavuzuna genel bakış.

Microsoft Azure hizmetlerinde güvenilirlik ve güvenilirlik ilkeleri ve mimarisi hakkında bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve: Güvenilirlik.

Güvenilirlik gereksinimleri

Herhangi bir Azure çözümü için gerekli güvenilirlik düzeyi, dikkat edilmesi gereken bazı noktalara bağlıdır. Kullanılabilirlik ve gecikme süresi SLA'sı ve diğer iş gereksinimleri mimari seçimleri ve dayanıklılık düzeyini yönlendirir ve önce dikkate alınmalıdır. Kullanılabilirlik gereksinimleri, kapalı kalma süresinin ne kadar kabul edilebilir olduğu ve işletmenize ne kadara mal olduğu ile bir uygulamayı yüksek oranda kullanılabilir hale getirmek için gerçekçi bir şekilde yatırım yapabileceğiniz para ve süreye kadar değişir.

Azure'da güvenilirlik sistemleri oluşturmak paylaşılan bir sorumluluktır. Microsoft, küresel ağı ve veri merkezleri dahil olmak üzere bulut platformunun güvenilirliğinden sorumludur. Azure müşterileri ve iş ortakları, her iş yükünün gereksinimlerine göre mimari en iyi yöntemleri kullanarak bulut uygulamalarının dayanıklılığından sorumludur. Azure, bulut platformu için SLA'da mümkün olan en yüksek dayanıklılık için sürekli çaba harcasa da çözümünüzdeki her iş yükü için kendi hedef SLA'larınızı tanımlamanız gerekir. SLA, mimarinin iş gereksinimlerini karşılayıp karşılamadığını değerlendirmeyi mümkün kılar. SLA garantili çalışma süresinin daha yüksek yüzdeleri için çabaladıkça, bu kullanılabilirlik düzeyini elde etmek için maliyet ve karmaşıklık artar. Yüzde 99,99 çalışma süresi, ayda yaklaşık beş dakikalık toplam kapalı kalma süresi anlamına gelir. Bu yüzdeye ulaşmak daha karmaşıklık ve maliyete değer mi? Yanıt, bireysel iş gereksinimlerine bağlıdır. Son SLA taahhütlerine karar verirken Microsoft'un desteklenen SLA'larını anlayın. Her Azure hizmetinin kendi SLA'sı vardır.

Diagram showing the shared responsibility model for Azure business continuity.

Geleneksel şirket içi modelde işlem, depolama ve ağ donanımından uygulamaya kadar tüm yönetim sorumluluğu size aittir. Bir olağanüstü durum kurtarma stratejisi oluşturarak çeşitli hata türlerini ve bunlarla nasıl başa çıkabileceğinizi planlamanız gerekir. IaaS ile bulut hizmeti sağlayıcısı depolama, ağ ve işlem gibi temel altyapı dayanıklılığından sorumludur. IaaS'den PaaS'a ve ardından SaaS'ye geçtikçe, daha azdan sorumlu olduğunuzu ve bulut hizmeti sağlayıcısının daha fazlasından sorumlu olduğunu göreceksiniz.  

Güvenilirlik ilkeleri hakkında daha fazla bilgi için iyi tasarlanmış Çerçeve Güvenilirliği belgelerine bakın.  

Güvenilirlik oluşturma

Planlamanın başında uygulamanızın güvenilirlik gereksinimlerini tanımlamanız gerekir. Belirli dönemlerde hangi uygulamaların %100 yüksek kullanılabilirliğe ihtiyacı olmadığını biliyorsanız, bu kritik olmayan dönemlerde maliyetleri iyileştirebilirsiniz. Bir uygulamanın karşılaşabileceği hataların türünü ve her bir hatanın olası etkisini belirleyin. Kurtarma planı, tek tek bileşende ve genel uygulama düzeyinde kurtarma stratejisini sonlandırarak tüm kritik hizmetleri kapsamalıdır. Bölgesel, bölgesel ve uygulama düzeyinde hatalara karşı koruma sağlamak için kurtarma stratejinizi tasarlar. Uygulama güvenilirliğini ve kurtarmayı beklenmeyen hatalara karşı ölçmek için uçtan uca uygulama ortamının testini gerçekleştirin.

Aşağıdaki denetim listesi güvenilirlik planlamasının kapsamını kapsar.

Güvenilirlik planlaması
İş gereksinimlerini karşılamak için kullanılabilirlik ve kurtarma hedeflerini tanımlayın .
Kullanılabilirlik gereksinimlerine göre uygulamalarınızın güvenilirlik özelliklerini tasarlayın .
Güvenilirlik gereksinimlerinizi karşılamak için uygulamaları ve veri platformlarını uyumlu hale getirme.
Kullanılabilirliği yükseltmek için bağlantı yollarını yapılandırın .
Güvenilirliği artırmak ve maliyetleri iyileştirmek için uygun olduğunda kullanılabilirlik alanlarını ve olağanüstü durum kurtarma planlamasını kullanın .
Uygulama mimarinizin hatalara dayanıklı olduğundan emin olun .
SLA gereksinimleri karşılanmazsa ne olacağını bilin .
Sistemdeki olası hata noktalarını belirleyin ; uygulama tasarımı, bağlantı hattı kesintisini dağıtarak bağımlılık hatalarına tolerans göstermelidir.
Bağımlılıkları olmadığında çalışan uygulamalar oluşturun .

RTO ve RPO

Olağanüstü durum kurtarmayla ilgili olduğundan dikkate alınması gereken iki önemli ölçüm, kurtarma süresi hedefi ve kurtarma noktası hedefidir.  İşlevsel ve işlevsel olmayan tasarım gereksinimleri hakkında daha fazla bilgi için bkz . İyi tasarlanmış Çerçeve işlevsel ve işlevsiz gereksinimler.

  • Kurtarma süresi hedefi (RTO), bir olay sonrasında uygulamanın kullanılamıyor olmasının kabul edilebileceği en uzun süredir.

  • Kurtarma noktası hedefi (RPO), olağanüstü bir durum sırasında en uzun ne kadar sürelik veri kaybının kabul edilebilir olduğudur.

RTO ve RPO, bir sistemin işlevsel olmayan gereksinimleridir ve iş gereksinimlerine göre dikte edilmelidir. Bu değerleri türetmek için, risk değerlendirmesi yapmak ve kapalı kalma süresinin veya veri kaybının maliyetini net bir şekilde anlamak iyi bir fikir olabilir.  

Bölgeler ve kullanılabilirlik alanları

Bölgeler ve kullanılabilirlik alanları, güvenilirlik denkleminin büyük bir parçasıdır. Bölgeler birden çok fiziksel olarak ayrı kullanılabilirlik alanına sahiptir. Bu kullanılabilirlik alanları, fiziksel bölgeler arasında 2 dakikadan kısa gecikme süresine sahip yüksek performanslı bir ağ ile bağlanır. Düşük gecikme süresi, işler yolunda gitmediğinde verilerinizin eşitlenmiş ve erişilebilir kalmasına yardımcı olur. Bölgeler arasında ve bölgeler arasında otomatik olarak çoğaltılan ve kesintisiz hizmetler sunan uygulamalar ve veri altyapısının mimarisini oluştururken bu altyapıyı stratejik olarak kullanabilirsiniz.

Microsoft Azure hizmetleri kullanılabilirlik alanlarını destekler ve bölgeler arası kurtarma ve iş sürekliliği strateji gereksinimlerinizi desteklerken bulut operasyonlarınızı en uygun yüksek kullanılabilirlik düzeyinde yönlendirmek için etkinleştirilir.

Olağanüstü durum kurtarma planlaması için, diğer bölgelerle eşleştirilen bölgeler bölgeler arası çoğaltma sunar ve verileri diğer Azure bölgelerinde zaman uyumsuz olarak çoğaltarak koruma sağlar. Çifti olmayan bölgeler veri yerleşimi yönergelerini izler ve kullanılabilirlik alanları ve yerel olarak yedekli veya alanlar arası yedekli depolama ile yüksek kullanılabilirlik sunar. Müşterilerin RTO/RPO ihtiyaçlarına göre bölgeler arası olağanüstü durum kurtarmayı planlamaları gerekir.

Teknik ve mevzuat konuları (hizmet özellikleri, veri yerleşimi, uyumluluk gereksinimleri, gecikme süresi) temel alınarak gereksinimleriniz için en iyi bölgeyi seçin ve güvenilirlik stratejinizi geliştirmeye başlayın. Daha fazla bilgi için bkz . Azure bölgeleri ve kullanılabilirlik alanları.

Azure hizmet bağımlılıkları

Microsoft Azure hizmetleri, bulut operasyonlarınızı en uygun düzeyde yönlendirmek için küresel olarak kullanılabilir.

Azure bölgelerine dağıtılan Azure hizmetleri, Azure genel altyapı ürünleri sayfasında listelenir. Azure'daki bölgeleri ve Kullanılabilirlik Alanları daha iyi anlamak için bkz. Azure'da bölgeler ve Kullanılabilirlik Alanları.

Azure hizmetleri, yüksek kullanılabilirlik ve olağanüstü durum kurtarma dahil olmak üzere güvenilirlik için tasarlanmıştır. Tek bir mantıksal veri merkezine bağımlı hizmet yoktur (tek hata noktalarını önlemek için). Azure genel altyapı ürünlerinde listelenen bölgesel olmayan hizmetler, belirli bir Azure bölgesine bağımlılığı olmayan hizmetlerdir. Bölgesel olmayan hizmetler iki veya daha fazla bölgeye dağıtılır ve bölgesel bir hata varsa, hizmetin başka bir bölgedeki örneği müşterilere hizmet etmeye devam eder. Bazı bölgesel olmayan hizmetler, müşterilerin hizmetin çalıştığı temel sanal makinenin (VM) dağıtılacağı bölgeyi belirtmesine olanak tanır. Örneğin, Azure Sanal Masaüstü müşterilerin VM'nin bulunduğu bölge konumunu belirtmesini sağlar. Müşteri verilerini depolayan tüm Azure hizmetleri, müşterinin verilerinin depolanacağı belirli bölgeleri belirtmesine olanak sağlar. Bunun istisnası, coğrafi yerleşimi (Avrupa veya Kuzey Amerika gibi) olan Microsoft Entra Id'dir. Veri depolama yerleşimi hakkında daha fazla bilgi için bkz . Veri yerleşimi eşlemesi.

Uygulamalarınızın ve hizmetlerinizin mimarisini daha iyi oluşturmanıza yardımcı olması için Azure hizmetleri arasındaki bağımlılıkları anlamanız gerekiyorsa, Microsoft satışlarınızla veya müşteri temsilcinizle iletişime geçerek Azure hizmet bağımlılığı belgelerini isteyebilirsiniz. Bu belgede, denetim düzlemi hizmetleri gibi yaygın ana iç hizmetlere yönelik bağımlılıklar da dahil olmak üzere Azure hizmetlerinin bağımlılıkları listelenir. Bu belgeleri edinmek için bir Microsoft müşterisi olmanız ve Microsoft ile uygun gizlilik sözleşmesine (NDA) sahip olmanız gerekir.

Sonraki adımlar