Azure Dayanıklı İşlevler'de olağanüstü durum kurtarma ve coğrafi dağıtım
Microsoft, Azure hizmetlerinin her zaman kullanılabilir olmasını sağlamaya çalışır. Ancak planlanmamış hizmet kesintileri oluşabilir. Uygulamanız dayanıklılık gerektiriyorsa Microsoft, uygulamanızı coğrafi olarak yedeklilik için yapılandırmanızı önerir. Ayrıca, müşterilerin bölgesel hizmet kesintisini işlemek için bir olağanüstü durum kurtarma planına sahip olması gerekir. Olağanüstü durum kurtarma planının önemli bir parçası, birincil çoğaltmanın kullanılamaz duruma gelmesi durumunda uygulamanızın ve depolama alanınızın ikincil çoğaltmasına yük devretmeye hazırlanmaktır.
Dayanıklı İşlevler'da tüm durum varsayılan olarak Azure Depolama'da kalıcıdır. Görev hub'ı, düzenleme ve varlıklar için kullanılan Azure Depolama kaynaklarına yönelik mantıksal bir kapsayıcıdır. Orchestrator, activity ve entity işlevleri yalnızca aynı görev hub'ına ait olduklarında birbirleriyle etkileşime geçebilir. Bu belge, bu Azure Depolama kaynaklarını yüksek oranda kullanılabilir tutmaya yönelik senaryoları açıklarken görev hub'larına başvurur.
Not
Bu makaledeki kılavuzda, Dayanıklı İşlevler çalışma zamanı durumunu depolamak için varsayılan Azure Depolama sağlayıcısını kullandığınız varsayılır. Ancak, durumu SQL Server veritabanı gibi başka bir yerde depolayan alternatif depolama sağlayıcıları yapılandırmak mümkündür. Alternatif depolama sağlayıcıları için farklı olağanüstü durum kurtarma ve coğrafi dağıtım stratejileri gerekebilir. Alternatif depolama sağlayıcıları hakkında daha fazla bilgi için Dayanıklı İşlevler depolama sağlayıcıları belgelerine bakın.
Düzenleme ve varlıklar, KENDILERI HTTP veya desteklenen diğer Azure İşlevleri tetikleyici türlerinden biri aracılığıyla tetiklenen istemci işlevleri kullanılarak tetiklenebilir. Bunlar yerleşik HTTP API'leri kullanılarak da tetiklenebilir. Kolaylık olması için, bu makale Azure Depolama ve HTTP tabanlı işlev tetikleyicileri içeren senaryolara ve olağanüstü durum kurtarma etkinlikleri sırasında kullanılabilirliği artırmaya ve kapalı kalma süresini en aza indirme seçeneklerine odaklanacaktır. Service Bus veya Azure Cosmos DB tetikleyicileri gibi diğer tetikleyici türleri açıkça ele alınmaz.
Azure Depolama kullanımı tarafından yönlendirildiğinden aşağıdaki senaryolar Active-Passive yapılandırmalarını temel alır. Bu düzen, bir yedekleme (pasif) işlev uygulamasının farklı bir bölgeye dağıtılmasından oluşur. Traffic Manager, birincil (etkin) işlev uygulamasını HTTP kullanılabilirliği için izler. Birincil başarısız olursa yedekleme işlevi uygulamasına yük devredecektir. Daha fazla bilgi için bkz. Azure Traffic Manager'ınÖncelik Traffic-Routing Yöntemi.
Not
- Önerilen Active-Passive yapılandırması, bir istemcinin HTTP aracılığıyla her zaman yeni düzenleme tetikleyebilmesini sağlar. Ancak, depolamada aynı görev hub'ını paylaşan iki işlev uygulamasının olması sonucunda, bazı arka plan depolama işlemleri her ikisi arasında dağıtılır. Bu nedenle bu yapılandırma, ikincil işlev uygulaması için bazı ek çıkış maliyetlerine neden olur.
- Temel alınan depolama hesabı ve görev hub'ı birincil bölgede oluşturulur ve her iki işlev uygulaması tarafından da paylaşılır.
- Yedekli olarak dağıtılan tüm işlev uygulamalarının, HTTP aracılığıyla etkinleştirilmesi durumunda aynı işlev erişim anahtarlarını paylaşması gerekir. İşlevler Çalışma Zamanı, tüketicilerin işlev anahtarlarını program aracılığıyla eklemesine, silmesine ve güncelleştirmesine olanak tanıyan bir yönetim API'sini kullanıma sunar. Anahtar yönetimi, Azure Resource Manager API'leri kullanılarak da mümkündür.
Senaryo 1 - Paylaşılan depolama ile yük dengeli işlem
Azure'daki işlem altyapısı başarısız olursa işlev uygulaması kullanılamaz duruma gelebilir. Bu tür kapalı kalma sürelerini en aza indirmek için bu senaryoda farklı bölgelere dağıtılan iki işlev uygulaması kullanılır. Traffic Manager, birincil işlev uygulamasındaki sorunları algılayıp trafiği otomatik olarak ikincil bölgedeki işlev uygulamasına yönlendirecek şekilde yapılandırılır. Bu işlev uygulaması aynı Azure Depolama hesabını ve Görev Hub'ını paylaşır. Bu nedenle işlev uygulamalarının durumu kaybolmaz ve çalışma normal şekilde devam edebilir. Sistem durumu birincil bölgeye geri yüklendikten sonra Azure Traffic Manager istekleri otomatik olarak bu işlev uygulamasına yönlendirmeye başlar.
Bu dağıtım senaryolarını kullanmanın çeşitli avantajları vardır:
- İşlem altyapısı başarısız olursa, iş yük devretme bölgesinde veri kaybı olmadan devam edebilir.
- Traffic Manager, iyi durumdaki işlev uygulamasına otomatik yük devretme işlemini otomatik olarak üstlenir.
- Traffic Manager, kesinti düzeltildikten sonra birincil işlev uygulamasına gelen trafiği otomatik olarak yeniden oluşturur.
Ancak, bu senaryo kullanıldığında şunları göz önünde bulundurun:
- İşlev uygulaması ayrılmış bir App Service planı kullanılarak dağıtılırsa, işlem altyapısının yük devretme veri merkezinde çoğaltılması maliyetleri artırır.
- Bu senaryo, işlem altyapısındaki kesintileri kapsar, ancak depolama hesabı işlev Uygulaması için tek hata noktası olmaya devam eder. Depolama kesintisi oluşursa uygulama kapalı kalma süresi yaşar.
- İşlev uygulaması yük devredilirse, bölgeler arasında depolama hesabına erişeceğinden gecikme süresi artar.
- Depolama hizmetine bulunduğu farklı bir bölgeden erişim, ağ çıkış trafiği nedeniyle daha yüksek maliyete neden olur.
- Bu senaryo Traffic Manager'a bağlıdır. Traffic Manager'ın nasıl çalıştığı göz önünde bulundurularak Dayanıklı İşlev kullanan bir istemci uygulamasının Traffic Manager'dan işlev uygulaması adresini yeniden sorgulaması gerekebilir.
Not
Dayanıklı İşlevler uzantısının v2.3.0'dan başlayarak, aynı depolama hesabı ve görev hub'ı yapılandırmasıyla iki işlev uygulaması aynı anda güvenli bir şekilde çalıştırılabilir. Başlatılacak ilk uygulama, diğer uygulamaların görev hub'ı kuyruklarından ileti çalmasını engelleyen bir uygulama düzeyinde blob kiralaması alır. Bu ilk uygulama çalışmayı durdurursa, kira süresi dolar ve ikinci bir uygulama tarafından alınabilir ve bu da görev hub'ı iletilerini işlemeye devam eder.
v2.3.0'dan önce, aynı depolama hesabını kullanacak şekilde yapılandırılan işlev uygulamaları iletileri işler ve depolama yapıtlarını eşzamanlı olarak güncelleştirir ve bu da genel gecikme sürelerinin ve çıkış maliyetlerinin çok daha yüksek olmasını sağlar. Birincil ve çoğaltma uygulamalarına geçici olarak bile olsa farklı kodlar dağıtıldıysa, iki uygulama genelinde orchestrator işlevi tutarsızlıkları nedeniyle düzenleme işlemleri de düzgün yürütülemeyebiliyor. Bu nedenle olağanüstü durum kurtarma amacıyla coğrafi dağıtım gerektiren tüm uygulamaların Dayanıklı uzantının v2.3.0 veya üzerini kullanması önerilir.
Senaryo 2 - Bölgesel depolama ile yük dengeli işlem
Yukarıdaki senaryo yalnızca işlem altyapısındaki hata durumunu kapsar. Depolama hizmeti başarısız olursa işlev uygulamasında kesintiye neden olur. Dayanıklı işlevlerin sürekli çalışmasını sağlamak için bu senaryo, işlev uygulamalarının dağıtıldığı her bölgede yerel bir depolama hesabı kullanır.
Bu yaklaşım önceki senaryoda iyileştirmeler ekler:
- İşlev uygulaması başarısız olursa Traffic Manager, ikincil bölgeye yük devretme işlemini üstlenir. Ancak işlev uygulaması kendi depolama hesabına bağlı olduğundan dayanıklı işlevler çalışmaya devam eder.
- Yük devretme sırasında, işlev uygulaması ve depolama hesabı birlikte bulunduğundan yük devretme bölgesinde ek gecikme olmaz.
- Depolama katmanının başarısız olması dayanıklı işlevlerde hatalara neden olur ve bu da yük devretme bölgesine yeniden yönlendirmeyi tetikler. Yine işlev uygulaması ve depolama alanı bölge başına yalıtıldığından dayanıklı işlevler çalışmaya devam eder.
Bu senaryo için önemli noktalar:
- İşlev uygulaması ayrılmış bir App Service planı kullanılarak dağıtılırsa, işlem altyapısının yük devretme veri merkezinde çoğaltılması maliyetleri artırır.
- Geçerli durum yük devretmedi, bu da birincil bölge kurtarılana kadar mevcut düzenlemelerin ve varlıkların etkin bir şekilde duraklatılacağını ve kullanılamayacağını gösterir.
Özetlemek gerekirse, birinci ve ikinci senaryo arasındaki denge, gecikme süresinin korunması ve çıkış maliyetlerinin en aza indirilmesidir, ancak kapalı kalma süresi boyunca mevcut düzenleme ve varlıklar kullanılamaz. Bu dezavantajların kabul edilebilir olup olmadığı, uygulamanın gereksinimlerine bağlıdır.
Senaryo 3 - GRS paylaşılan depolama alanı ile yük dengeli işlem
Bu senaryo, paylaşılan bir depolama hesabı uygulayan ilk senaryo üzerinde yapılan bir değişikliktir. Temel fark, depolama hesabının coğrafi çoğaltma etkin olarak oluşturulmasıdır. İşlevsel olarak, bu senaryo Senaryo 1 ile aynı avantajları sağlar, ancak ek veri kurtarma avantajları sağlar:
- Coğrafi olarak yedekli depolama (GRS) ve Okuma erişimli GRS (RA-GRS), depolama hesabınız için kullanılabilirliği en üst düzeye çıkarır.
- Depolama hizmetinde bölgesel bir kesinti varsa, ikincil çoğaltmaya el ile yük devretme başlatabilirsiniz. Bir bölgenin önemli bir olağanüstü durum nedeniyle kaybolduğu aşırı durumlarda, Microsoft bölgesel yük devretme başlatabilir. Bu durumda, sizin tarafınızda herhangi bir işlem yapılması gerekmez.
- Yük devretme gerçekleştiğinde dayanıklı işlevlerin durumu, genellikle birkaç dakikada bir gerçekleşen depolama hesabının son çoğaltmasına kadar korunur.
Diğer senaryolarda olduğu gibi, dikkat edilmesi gereken önemli noktalar vardır:
- Çoğaltmaya yük devretme işlemi biraz zaman alabilir. Yük devretme tamamlanana ve Azure Depolama DNS kayıtları güncelleştirilene kadar işlev uygulamasında bir kesinti yaşanacaktır.
- Coğrafi olarak çoğaltılan depolama hesaplarını kullanmanın maliyeti artar.
- GRS çoğaltması, verilerinizi zaman uyumsuz olarak kopyalar. Çoğaltma işleminin gecikme süresi nedeniyle en son işlemlerden bazıları kaybolabilir.
Not
Senaryo 1'de açıklandığı gibi, bu stratejiyle dağıtılan işlev uygulamalarının Dayanıklı İşlevler uzantısının v2.3.0 veya üzerini kullanması kesinlikle önerilir.
Daha fazla bilgi için Bkz. Azure Depolama olağanüstü durum kurtarma ve depolama hesabı yük devretme belgeleri.