Azure Logic Apps için iş sürekliliği ve olağanüstü durum kurtarma

Öngörülemeyen olayların işletmeniz ve müşterileriniz üzerindeki etkisini ve etkilerini azaltmaya yardımcı olmak için, verileri koruyabilmeniz, kritik iş işlevlerini destekleyen kaynakları hızlı bir şekilde geri yükleyebilmeniz ve iş sürekliliğini (BC) sürdürmek için işlemleri çalışır durumda tutabilmeniz için bir olağanüstü durum kurtarma (DR) çözümünüz olduğundan emin olun. Örneğin kesintiler arasında kesintiler, temel altyapıdaki kayıplar veya depolama, ağ veya işlem kaynakları gibi bileşenler, kurtarılamayan uygulama hataları ve hatta tam veri merkezi kaybı sayılabilir. İşletmeniz veya kuruluşunuz, iş sürekliliği ve olağanüstü durum kurtarma (BCDR) çözümünü hazır hale getirmek suretiyle kesintilere, planlı veya plansız çözümlere daha hızlı yanıt verebilir ve müşterileriniz için kapalı kalma süresini azaltabilir.

Bu makalede, Azure Logic Apps kullanarak otomatik iş akışları oluştururken uygulayabileceğiniz BCDR yönergeleri ve stratejileri sağlanır. Mantıksal uygulama iş akışları, yazmanız gereken kodu azaltarak uygulamalar, bulut hizmetleri ve şirket içi sistemler arasında verileri daha kolay tümleştirmenize ve düzenlemenize yardımcı olur. BCDR'yi planlarken yalnızca mantıksal uygulamalarınızı değil mantıksal uygulamalarınızla birlikte kullandığınız Azure kaynaklarını da göz önünde bulundurduğunuzdan emin olun:

• Mantıksal uygulama iş akışlarından diğer uygulamalara, hizmetlere ve sistemlere oluşturduğunuz bağlantılar. Daha fazla bilgi için bu konunun devamında yer alan Kaynaklara bağlantılar bölümüne bakın.

• Şirket içi sistemlerdeki verilere erişmek için mantıksal uygulamalarınızda oluşturduğunuz ve kullandığınız Azure kaynakları olan şirket içi veri ağ geçitleri . Her ağ geçidi kaynağı, yerel bilgisayarda ayrı bir veri ağ geçidi yüklemesini temsil eder. Daha fazla bilgi için bu konunun devamında yer alan Şirket içi veri ağ geçitleri bölümüne bakın.

• Mantıksal uygulamaların işletmeler arası (B2B) kurumsal tümleştirme senaryoları için kullandığı yapıtları tanımladığınız ve depoladığınız tümleştirme hesapları. Örneğin, tümleştirme hesapları için bölgeler arası olağanüstü durum kurtarma ayarlayabilirsiniz.

Birincil ve ikincil konumlar

Her mantıksal uygulamanın dağıtım için kullanmak istediğiniz konumu (örneğin, bir Azure bölgesi, örneğin "Batı ABD") belirtmesi gerekir. Bu olağanüstü durum kurtarma stratejisi, birincil mantıksal uygulamanızı Azure Logic Apps'in de kullanılabildiği alternatif bir konumdaki bir bekleme veya yedekleme mantıksal uygulamasına yük devretmek üzere ayarlamaya odaklanır. Bu şekilde, birincil kişi kayıplar, kesintiler veya hatalar yaşıyorsa, ikincil iş üstlenebilir. Bu strateji, ikincil mantıksal uygulamanızın ve bağımlı kaynaklarınızın alternatif konumda zaten dağıtılıp hazır olmasını gerektirir.

İyi DevOps uygulamalarını izlerseniz mantıksal uygulamalarınızı ve bunların bağımlı kaynaklarını tanımlamak ve dağıtmak için Zaten Azure Resource Manager şablonlarını kullanırsınız. Resource Manager şablonları size tek bir dağıtım tanımı kullanma ve ardından parametre dosyalarını kullanarak her dağıtım hedefi için kullanılacak yapılandırma değerlerini sağlama olanağı sağlar. Bu özellik, aynı mantıksal uygulamayı geliştirme, test ve üretim gibi farklı ortamlara dağıtabileceğiniz anlamına gelir. Aynı mantıksal uygulamayı, eşleştirilmiş bölgeleri kullanan olağanüstü durum kurtarma stratejilerini destekleyen farklı Azure bölgelerine de dağıtabilirsiniz.

Yük devretme stratejisi için mantıksal uygulamalarınız ve konumlarınız şu gereksinimleri karşılamalıdır:

• İkincil mantıksal uygulama örneği, birincil mantıksal uygulama örneğiyle aynı uygulamalara, hizmetlere ve sistemlere erişebilir.

• Her iki mantıksal uygulama örneği de aynı konak türüne sahiptir. Bu nedenle, her iki örnek de küresel çok kiracılı Azure Logic Apps'teki bölgelere veya tek kiracılı Azure Logic Apps'teki bölgelere dağıtılır. BCDR için en iyi yöntemler ve eşleştirilmiş bölgeler hakkında daha fazla bilgi için bkz . Azure'da bölgeler arası çoğaltma: İş sürekliliği ve olağanüstü durum kurtarma.

Örnek: Çok Kiracılı Azure

Bu örnek, bu senaryo için genel çok kiracılı Azure'da ayrı bölgelere dağıtılan birincil ve ikincil mantıksal uygulama örneklerini gösterir. Tek bir Resource Manager şablonu hem mantıksal uygulama örneklerini hem de bu mantıksal uygulamaların gerektirdiği bağımlı kaynakları tanımlar. Ayrı parametre dosyaları, her dağıtım konumu için kullanılacak yapılandırma değerlerini belirtir:

Kaynaklara bağlantılar

Azure Logic Apps, mantıksal uygulama iş akışınızın Azure Depolama hesapları, SQL Server veritabanları, iş veya okul e-posta hesapları gibi diğer uygulamalar, hizmetler, sistemler ve diğer kaynaklarla çalışmak için kullanabileceği yüzlerce bağlayıcı işlemi sağlar. Mantıksal uygulamanızın bu kaynaklara erişmesi gerekiyorsa, bu kaynaklara erişimin kimliğini doğrulayan bağlantılar oluşturursunuz. Her bağlantı, belirli bir konumda bulunan ve diğer konumlardaki kaynaklar tarafından kullanılamayan ayrı bir Azure kaynağıdır.

Olağanüstü durum kurtarma stratejiniz için, mantıksal uygulama örneklerinize göre bağımlı kaynakların bulunduğu konumları göz önünde bulundurun:

• Birincil örneğin ve bağımlı kaynaklarınız farklı konumlarda bulunur. Bu durumda, ikincil örneğiniz aynı bağımlı kaynaklara veya uç noktalara bağlanabilir. Ancak, özellikle ikincil örneğine yönelik bağlantılar oluşturmanız gerekir. Bu şekilde birincil konumunuz kullanılamaz duruma gelirse ikincil konumunuzun bağlantıları etkilenmez.

  Örneğin, birincil mantıksal uygulamanızın Salesforce gibi bir dış hizmete bağlandığını varsayalım. Genellikle dış hizmetin kullanılabilirliği ve konumu mantıksal uygulamanızın kullanılabilirlik alanından bağımsızdır. Bu durumda, ikincil örneğiniz aynı hizmete bağlanabilir ancak kendi bağlantısı olmalıdır.

• Hem birincil örneğiniz hem de bağımlı kaynaklarınız aynı konumda bulunur. Bu durumda, ikincil örneğinizin bu kaynaklara erişmeye devam edebilmesi için bağımlı kaynakların yedekleri veya çoğaltılmış sürümleri farklı bir konumda olmalıdır.

  Örneğin, birincil mantıksal uygulamanızın aynı konumda veya bölgede bulunan bir hizmete (örneğin, Azure SQL Veritabanı) bağlandığını varsayalım. Bu bölgenin tamamı kullanılamaz duruma gelirse, bu bölgedeki Azure SQL Veritabanı hizmeti de muhtemelen kullanılamaz. Bu durumda, ikincil örneğinizin çoğaltılmış veya yedek veritabanı ile bu veritabanına ayrı bir bağlantı kullanmasını istersiniz.

Şirket içi veri ağ geçitleri

Mantıksal uygulamanız çok kiracılı Azure'da çalışıyorsa ve SQL Server veritabanları gibi şirket içi kaynaklara erişmesi gerekiyorsa, şirket içi veri ağ geçidini yerel bir bilgisayara yüklemeniz gerekir. Ardından, mantıksal uygulamanızın kaynakla bağlantı oluşturduğunuzda ağ geçidini kullanabilmesi için Azure portalında bir veri ağ geçidi kaynağı oluşturabilirsiniz.

Veri ağ geçidi kaynağı, mantıksal uygulama kaynağınız gibi bir konum veya Azure bölgesiyle ilişkilendirilir. Olağanüstü durum kurtarma stratejinizde, mantıksal uygulamanızın kullanabileceği veri ağ geçidinin kullanılabilir durumda kaldığından emin olun. Birden çok ağ geçidi yüklemeniz olduğunda ağ geçidiniz için yüksek kullanılabilirliği etkinleştirebilirsiniz.

Etkin-etkin ve aktif-pasif rolleri karşılaştırması

Birincil ve ikincil konumlarınızı, bu konumlardaki mantıksal uygulama örneklerinizin şu rolleri yürütebilmesi için ayarlayabilirsiniz:

Etkin-etkin örnekler

Bu örnekler, her iki mantıksal uygulama örneğinin de istekleri veya iletileri etkin olarak işlediği etkin-etkin kurulumu gösterir. Başka bir sistem veya hizmet, istekleri veya iletileri örnekler arasında dağıtır, örneğin, şu seçeneklerden biri:

• Trafiği yönlendiren bir donanım parçası gibi "fiziksel" bir yük dengeleyici

• Azure Load Balancer veya Azure API Management gibi "yumuşak" bir yük dengeleyici. API Management ile gelen trafiğin yük dengelemesini belirleyen ilkeler belirtebilirsiniz. Öte yandan durum izlemeyi destekleyen bir hizmet de kullanabilirsiniz; örneğin, Azure Service Bus.

  Bu örnek öncelikli olarak Azure Load Balancer'ı gösterse de senaryonuzun gereksinimlerine en uygun seçeneği kullanabilirsiniz:

  

• Her mantıksal uygulama örneği tüketici işlevi görür ve her iki örneğin de kuyruktan gelen iletiler için rekabet etmesi gerekir:

  

Etkin-pasif örnekler

Bu örnekte, birincil mantıksal uygulama örneğinin bir konumda etkin olduğu, ikincil örneğin ise başka bir konumda etkin olmadığı etkin-pasif kurulum gösterilmektedir. Birincil bir kesinti veya hatayla karşılaşırsa, bir operatörün iş yükünü almak için ikincilyi etkinleştiren bir betik çalıştırmasını sağlayabilirsiniz.

Aktif-aktif ve aktif-pasif ile kombinasyon

Bu örnekte, birincil konumun her iki etkin mantıksal uygulama örneğine sahip olduğu, ikincil konumda ise etkin-pasif mantıksal uygulama örneklerinin bulunduğu birleşik bir kurulum gösterilmektedir. Birincil konum bir kesinti veya hatayla karşılaşırsa, kısmi bir iş yükünü zaten işleyen ikincil konumdaki etkin mantıksal uygulama iş yükünün tamamını devralabilir.

• Birincil konumda, etkin bir mantıksal uygulama iletiler için Azure Service Bus kuyruğu dinlerken, başka bir etkin mantıksal uygulama office 365 Outlook yoklama tetikleyicisi kullanarak e-postaları denetler.

• İkincil konumda etkin bir mantıksal uygulama, aynı Service Bus kuyruğundan gelen iletileri dinleyerek ve bunlarla rekabet ederek birincil konumda mantıksal uygulamayla birlikte çalışır. Bu arada pasif etkin olmayan bir mantıksal uygulama, birincil konum kullanılamaz duruma geldiğinde e-postaları denetlemek için beklemede bekler, ancak e-postaların yeniden okunmasını önlemek için devre dışı bırakılır.

Mantıksal uygulama durumu ve geçmişi

Mantıksal uygulamanız tetiklendiğinde ve çalışmaya başladığında, uygulamanın durumu uygulamanın başladığı konumda depolanır ve başka bir konuma aktarılamaz. Bir hata veya kesinti oluşursa, devam eden iş akışı örnekleri terk edilir. Birincil ve ikincil konumlarınız ayarlandığında, yeni iş akışı örnekleri ikincil konumda çalışmaya başlar.

Terk edilen devam eden örnekleri azaltma

Bırakılan devam eden iş akışı örneklerinin sayısını en aza indirmek için uygulayabileceğiniz çeşitli ileti desenleri arasından seçim yapabilirsiniz, örneğin:

• Sabit yönlendirme notu deseni

  Bir iş sürecini daha küçük aşamalara ayıran bu kurumsal ileti düzeni. Her aşama için, bu aşama için iş yükünü işleyen bir mantıksal uygulama ayarlarsınız. Mantıksal uygulamalarınız birbirleriyle iletişim kurmak için Azure Service Bus kuyrukları veya konuları gibi zaman uyumsuz bir mesajlaşma protokolü kullanır. Bir işlemi daha küçük aşamalara böldüğünüzde, başarısız bir mantıksal uygulama örneğinde takılmış olabilecek iş süreçlerinin sayısını azaltırsınız. Bu desen hakkında daha fazla genel bilgi için bkz . Kurumsal tümleştirme desenleri - Yönlendirme notu.

  Bu örnekte, her mantıksal uygulamanın bir aşamayı temsil ettiği ve işlemdeki bir sonraki mantıksal uygulamayla iletişim kurmak için Service Bus kuyruğu kullandığı bir yönlendirme notu deseni gösterilmektedir.

  

  Hem birincil hem de ikincil mantıksal uygulama örnekleri konumlarında aynı yönlendirme notu desenini izlerse, bu örnekler için etkin-etkin roller ayarlayarak rakip tüketici desenini uygulayabilirsiniz.

• İşlem yöneticisi (aracı) deseni

• Zaman aşımı düzeni olmadan göz atma-kilitleme

Tetikleyici ve çalıştırma geçmişine erişim

Mantıksal uygulamanızın geçmiş iş akışı yürütmeleri hakkında daha fazla bilgi edinmek için uygulamanın tetikleyicisini ve çalıştırma geçmişini gözden geçirebilirsiniz. Mantıksal uygulamanın yürütme geçmişi, mantıksal uygulamanın çalıştırıldığı aynı konumda veya bölgede depolanır; başka bir deyişle bu geçmişi farklı bir konuma geçiremezsiniz. Birincil örneğiniz ikincil örneğe yük devrederse, her örneğin tetikleyicisine erişebilir ve bu örneklerin çalıştırıldığı ilgili konumlarda çalıştırma geçmişine erişebilirsiniz. Ancak mantıksal uygulamalarınızı bir Azure Log Analytics çalışma alanına tanılama olayları gönderecek şekilde ayarlayarak mantıksal uygulamanızın geçmişi hakkında konum bilgisi alabilirsiniz. Daha sonra birden çok konumda çalışan mantıksal uygulamalar genelinde sistem durumunu ve geçmişini gözden geçirebilirsiniz.

Tetikleyici türü kılavuzu

Mantıksal uygulamalarınızda kullandığınız tetikleyici türü, olağanüstü durum kurtarma stratejinizdeki konumlar arasında mantıksal uygulamaları nasıl ayarlayabileceğinize ilişkin seçeneklerinizi belirler. Mantıksal uygulamalarda kullanabileceğiniz kullanılabilir tetikleyici türleri şunlardır:

• Yinelenme tetikleyicisi
• Yoklama tetikleyicisi
• İstek tetikleyicisi
• Web kancası tetikleyicisi

Yinelenme tetikleyicisi

Yinelenme tetikleyicisi belirli bir hizmetten veya uç noktadan bağımsızdır ve yalnızca belirli bir zamanlamaya göre tetikler ve başka ölçüt oluşturmaz, örneğin:

• Sabit bir sıklık ve aralık, örneğin 10 dakikada bir
• Her ayın son Pazartesi günü saat 17:00 gibi daha gelişmiş bir zamanlama

Mantıksal uygulamanız Bir Yinelenme tetikleyicisi ile başladığında, birincil ve ikincil mantıksal uygulama örneklerinizi etkin-pasif rollerle ayarlamanız gerekir. Bir kesinti veya olağanüstü durum sonrasında iş sürecini geri yüklemeye yönelik hedef süreyi ifade eden kurtarma süresi hedefini (RTO) azaltmak için mantıksal uygulama örneklerinizi etkin-pasif roller ve pasif-etkin rollerin bir bileşimiyle ayarlayabilirsiniz. Bu kurulumda, zamanlamayı konumlar arasında bölersiniz.

Örneğin, 10 dakikada bir çalışması gereken bir mantıksal uygulamanız olduğunu varsayalım. Mantıksal uygulamalarınızı ve konumlarınızı ayarlayarak birincil konumun kullanılamaz duruma gelmesi durumunda ikincil konumun işi devralabilmesini sağlayabilirsiniz:

• Birincil konumda, bu mantıksal uygulamalar için etkin-pasif rolleri ayarlayın:

  • Etkin etkin mantıksal uygulama için Yinelenme tetikleyicisini saatin en üstünde başlayacak şekilde ayarlayın ve 20 dakikada bir (örneğin, 09:00, 09:20 vb.) yineleyin.

  • Pasif devre dışı mantıksal uygulama için Yinelenme tetikleyicisini aynı zamanlamaya ayarlayın, ancak saati 10 dakika geçe başlayıp 20 dakikada bir (örneğin, 09:10, 09:30 vb.) yineleyin.

• İkincil konumda, bu mantıksal uygulamalar için pasif-etkin ayarlayın:

  • Pasif devre dışı bırakılmış mantıksal uygulama için, Yinelenme tetikleyicisini birincil konumdaki etkin mantıksal uygulamayla aynı zamanlamaya ayarlayın. Bu, saatin en üstündedir ve 9:00, 09:10 gibi her 20 dakikada bir tekrarlanır.

  • Etkin etkin mantıksal uygulama için, Yinelenme tetikleyicisini birincil konumdaki pasif mantıksal uygulamayla aynı zamanlamaya ayarlayın. Bu, saati 10 dakika geçe başlayıp 20 dakikada bir (örneğin, 09:10, 09:20 vb.) yineleyin.

Şimdi birincil konumda kesintiye neden olan bir olay olursa pasif mantıksal uygulamayı alternatif konumda etkinleştirin. Bu şekilde, hatanın bulunması zaman alırsa, bu kurulum bu gecikme sırasında kaçırılan yineleme sayısını sınırlar.

Yoklama tetikleyicisi

İşleme için yeni verilerin belirli bir hizmetten veya uç noktadan kullanılabilir olup olmadığını düzenli olarak denetlemek için mantıksal uygulamanız, sabit bir yineleme zamanlamasına göre hizmeti veya uç noktayı sürekli çağıran bir yoklama tetikleyicisi kullanabilir. Hizmet veya uç noktanın sağladığı veriler şu türlerden herhangi birini içerebilir:

• Her zaman okunabilen verileri açıklayan statik veriler
• Okundıktan sonra artık kullanılamayan verileri açıklayan geçici veriler

Aynı verilerin tekrar tekrar okunmasını önlemek için mantıksal uygulamanızın istemci tarafında veya sunucu, hizmet veya sistem tarafında durumu koruyarak hangi verilerin daha önce okunmuş olduğunu hatırlaması gerekir.

• İstemci tarafı durumuyla çalışan mantıksal uygulamalar, durumu koruyabilen tetikleyiciler kullanır.

  Örneğin, e-posta gelen kutusundan yeni bir ileti okuyan bir tetikleyici, tetikleyicinin en son okunan iletiyi anımsamasını gerektirir. Bu şekilde tetikleyici mantıksal uygulamayı yalnızca bir sonraki okunmamış ileti geldiğinde başlatır.

• Sunucu, hizmet veya sistem tarafı durumuyla çalışan mantıksal uygulamalar, sunucu, hizmet veya sistem tarafında bulunan özellik değerlerini veya ayarlarını kullanır.

  Örneğin, veritabanından satır okuyan sorgu tabanlı tetikleyici, satırın olarak ayarlanmış FALSEbir isRead sütunu olmasını gerektirir. Tetikleyici bir satırı her okuduğunda mantıksal uygulama sütunu olarak FALSE TRUEdeğiştirerek isRead bu satırı güncelleştirir.

  Bu sunucu tarafı yaklaşımı, bir tetikleyicinin iletiyi işlerken bir iletiyi okuyup kilitleyebildiği sıraya alma semantiğine sahip Service Bus kuyrukları veya konu başlıkları için benzer şekilde çalışır. Mantıksal uygulama işlemeyi tamamladığında, tetikleyici iletiyi kuyruktan veya konu başlığından siler.

Olağanüstü durum kurtarma perspektifinden bakıldığında, mantıksal uygulamanızın birincil ve ikincil örneklerini ayarlarken, mantıksal uygulamanızın istemci tarafında veya sunucu tarafında durumu izlemesine bağlı olarak bu davranışları hesaba katın:

• İstemci tarafı durumuyla çalışan bir mantıksal uygulama için mantıksal uygulamanızın aynı iletiyi birden çok kez okumadığından emin olun. Herhangi bir zamanda yalnızca bir konumda etkin bir mantıksal uygulama örneği olabilir. Birincil örnek alternatif konuma devredinceye kadar alternatif konumdaki mantıksal uygulama örneğinin devre dışı veya devre dışı olduğundan emin olun.

  Örneğin, Office 365 Outlook tetikleyicisi istemci tarafı durumunu korur ve yinelenen bir e-postayı okumamak için en son okunan e-postanın zaman damgasını izler.

• Sunucu tarafı durumuyla çalışan bir mantıksal uygulama için mantıksal uygulama örneklerinizi, rakip tüketici olarak çalıştıkları etkin-etkin rolleri veya birincil örneğin alternatif konuma devredilmesi için alternatif örneğin beklediği etkin-pasif rolleri oynatacak şekilde ayarlayabilirsiniz.

  Örneğin, Azure Service Bus kuyruğu gibi bir ileti kuyruğundan okuma, sunucu tarafı durumunu kullanır çünkü kuyruğa alma hizmeti, diğer istemcilerin aynı iletileri okumasını önlemek için iletilerde kilitler tutar.

  Not

  Mantıksal uygulamanızın iletileri belirli bir sırada, örneğin service Bus kuyruğundan okuması gerekiyorsa, rakip tüketici desenini kullanabilirsiniz, ancak yalnızca sıralı konvoy düzeni olarak da bilinen Service Bus oturumlarıyla birleştirildiğinde kullanabilirsiniz. Aksi takdirde, mantıksal uygulama örneklerinizi etkin-pasif rollerle ayarlamanız gerekir.

İstek tetikleyicisi

İstek tetikleyicisi mantıksal uygulamanızı diğer uygulamalardan, hizmetlerden ve sistemlerden çağrılabilir hale getirir ve genellikle şu özellikleri sağlamak için kullanılır:

• Başkalarının çağırabileceği mantıksal uygulamanız için doğrudan REST API

  Örneğin, diğer mantıksal uygulamaların İş akışını çağır - Logic Apps eylemini kullanarak tetikleyiciyi çağırabilmesi için mantıksal uygulamanızı başlatmak için İstek tetikleyicisini kullanın.

• Mantıksal uygulamanız için bir web kancası veya geri çağırma mekanizması

• Mantıksal uygulamanızı çağırmak için kullanıcı işlemlerini veya yordamlarını el ile çalıştırmanın bir yolu, örneğin, belirli bir görevi gerçekleştiren bir PowerShell betiği kullanarak

Olağanüstü durum kurtarma perspektifinden bakıldığında, mantıksal uygulama herhangi bir iş yapmadığından ve başka bir hizmet veya sistem açıkça tetikleyiciyi çağırana kadar beklediğinden İstek tetikleyicisi pasif bir alıcıdır. Pasif uç nokta olarak, birincil ve ikincil örneklerinizi şu yollarla ayarlayabilirsiniz:

• Etkin-etkin: her iki örnek de istekleri veya çağrıları etkin bir şekilde işler. Arayan veya yönlendirici, trafiği bu örnekler arasında dengeler veya dağıtır.

• Etkin-pasif: Yalnızca birincil örnek etkindir ve tüm işleri işlerken, ikincil örnek kesinti veya hatayla karşılaşana kadar bekler. Arayan veya yönlendirici, ikincil örneğin ne zaman çağrıldığını belirler.

Önerilen mimari olarak, İstek tetikleyicilerini kullanan mantıksal uygulamalar için ara sunucu olarak Azure API Management'ı kullanabilirsiniz. API Management, yerleşik bölgeler arası dayanıklılık ve trafiği birden çok uç nokta arasında yönlendirme olanağı sağlar.

Web kancası tetikleyicisi

Web kancası tetikleyicisi, mantıksal uygulamanızın bir hizmete geri çağırma URL'si geçirerek hizmete abone olma özelliğini sağlar. Mantıksal uygulamanız daha sonra bu hizmet uç noktasında belirli bir olayın gerçekleşmesini dinleyebilir ve bekleyebilir. Olay gerçekleştiğinde hizmet, mantıksal uygulamayı çalıştıran geri çağırma URL'sini kullanarak web kancası tetikleyicisini çağırır. Etkinleştirildiğinde web kancası tetikleyicisi hizmete abonedir. Devre dışı bırakıldığında tetikleyici hizmet aboneliğini kaldırır.

Olağanüstü durum kurtarma perspektifinden bakıldığında, yalnızca bir örneğin abone olunan uç noktadan olay veya ileti alması gerektiğinden, etkin-pasif rolleri yürütmek için web kancası tetikleyicileri kullanan birincil ve ikincil örnekleri ayarlayın.

Birincil örnek durumunu değerlendirme

Olağanüstü durum kurtarma stratejinizin çalışması için çözümünüz şu görevleri gerçekleştirmek için yöntemlere ihtiyaç duyar:

• Birincil örneğin kullanılabilirliğini denetleme
• Birincil örneğin durumunu izleme
• İkincil örneği etkinleştirme

Bu bölümde, kendi tasarımınız için doğru veya temel olarak kullanabileceğiniz bir çözüm açıklanmaktadır. Bu çözüm için üst düzey bir görsele genel bakış aşağıdadır:

Birincil örnek kullanılabilirliğini denetleme

Birincil örneğin kullanılabilir, çalışır ve çalışabilir olup olmadığını belirlemek için, birincil örnekle aynı konumda bulunan bir "sistem durumu denetimi" mantıksal uygulaması oluşturabilirsiniz. Daha sonra bu sistem durumu denetimi uygulamasını alternatif bir konumdan çağırabilirsiniz. Sistem durumu denetimi uygulaması başarıyla yanıt verirse, bu bölgedeki Azure Logic Apps hizmeti için temel altyapı kullanılabilir ve çalışır. Sistem durumu denetimi uygulaması yanıt vermezse konumun artık iyi durumda olmadığını varsayabilirsiniz.

Bu görev için, şu görevleri gerçekleştiren temel bir sistem durumu denetimi mantıksal uygulaması oluşturun:

1. İstek tetikleyicisini kullanarak watchdog uygulamasından bir çağrı alır.

2. Yanıt eylemini kullanarak denetlenen mantıksal uygulamanın hala çalışıp çalışmadığını belirten bir durumla yanıt verin.

   Önemli

   Sistem durumu denetimi mantıksal uygulaması, uygulamanın zaman uyumsuz değil zaman uyumlu bir şekilde yanıt vermesi için bir Yanıt eylemi kullanmalıdır.

3. İsteğe bağlı olarak, birincil konumun iyi durumda olup olmadığını daha fazla belirlemek için, bu konumdaki hedef mantıksal uygulamayla etkileşime geçen diğer hizmetlerin durumunu dikkate alabilirsiniz. Bu diğer hizmetlerin de sistem durumunu değerlendirmek için sistem durumu denetimi mantıksal uygulamasını genişletmesi yeterlidir.

watchdog mantıksal uygulaması oluşturma

Birincil örneğin durumunu izlemek ve sistem durumu denetimi mantıksal uygulamasını çağırmak için alternatif bir konumda bir "watchdog" mantıksal uygulaması oluşturun. Örneğin, sistem durumu denetimi mantığının çağrılması başarısız olursa, watchdog'un hatayı ve birincil örneğin neden yanıt vermediğini araştırabilmesi için operasyon ekibinize bir uyarı gönderebilmesi için watchdog mantıksal uygulamasını ayarlayabilirsiniz.

Bu görev için, ikincil konumda şu görevleri gerçekleştiren bir izleme mantıksal uygulaması oluşturun:

1. Yinelenme tetikleyicisini kullanarak sabit veya zamanlanmış bir yinelenme temelinde çalıştırın.

   Yinelemeyi kurtarma süresi hedefiniz (RTO) için tolerans düzeyinin altında bir değere ayarlayabilirsiniz.

2. HTTP eylemini kullanarak birincil konumda sistem durumu denetimi mantıksal uygulama iş akışını çağırın.

Ayrıca, bir dizi hatadan sonra birincil başarısız olduğunda ikincil konuma geçişi otomatik olarak işleyen başka bir mantıksal uygulamayı çağıran daha gelişmiş bir watchdog mantıksal uygulaması da oluşturabilirsiniz.

İkincil örneğinizi etkinleştirme

İkincil örneği otomatik olarak etkinleştirmek için Azure Resource Manager bağlayıcısı gibi yönetim API'sini çağıran bir mantıksal uygulama oluşturarak ikincil konumda uygun mantıksal uygulamaları etkinleştirebilirsiniz. Belirli sayıda hata olduktan sonra watchdog uygulamanızı bu etkinleştirme mantıksal uygulamasını çağıracak şekilde genişletebilirsiniz.

Kullanılabilirlik alanlarıyla alanlar arası yedeklilik

Her Azure bölgesinde kullanılabilirlik alanları, yerel hatalara dayanıklı fiziksel olarak ayrı konumlardır. Bu tür hatalar, yazılım ve donanım arızalarından deprem, sel ve yangın gibi olaylara kadar değişebilir. Bu bölgeler, Azure hizmetlerinin yedekliliği ve mantıksal yalıtımı aracılığıyla tolerans elde eder.

Dayanıklılık ve dağıtılmış kullanılabilirlik sağlamak için, herhangi bir Azure bölgesinde alanlar arası yedekliliği destekleyen ve etkinleştiren en az üç ayrı kullanılabilirlik alanı vardır. Azure Logic Apps platformu bu bölgeleri ve mantıksal uygulama iş yüklerini bu bölgelere dağıtır. Bu özellik, dayanıklı mimarileri etkinleştirmek ve bir bölgede veri merkezi hataları oluşursa yüksek kullanılabilirlik sağlamak için önemli bir gereksinimdir.

Şu anda bu özellik önizleme aşamasındadır ve belirli bölgelerdeki yeni Tüketim mantığı uygulamaları için kullanılabilir. Daha fazla bilgi için, aşağıdaki belgelere bakın:

• Bölge yedekliliği ve kullanılabilirlik alanlarıyla Tüketim mantığı uygulamalarını bölge hatalarından koruma
• Azure bölgeleri ve kullanılabilirlik alanları

Tanılama verilerini toplama

Mantıksal uygulama çalıştırmalarınız için günlüğe kaydetmeyi ayarlayabilir ve daha fazla işleme ve işleme için elde edilen tanılama verilerini Azure Depolama, Azure Event Hubs ve Azure Log Analytics gibi hizmetlere gönderebilirsiniz.

• Bu verileri Azure Log Analytics ile kullanmak istiyorsanız mantıksal uygulamanızın Tanılama ayarlarını ayarlayarak ve verileri birden çok Log Analytics çalışma alanına göndererek verileri hem birincil hem de ikincil konumlar için kullanılabilir hale getirebilirsiniz. Daha fazla bilgi için bkz . Azure İzleyici günlüklerini ayarlama ve Azure Logic Apps için tanılama verilerini toplama.

• Verileri Azure Depolama'ya veya Azure Event Hubs'a göndermek istiyorsanız coğrafi olarak yedeklilik ayarlayarak verileri hem birincil hem de ikincil konumlar için kullanılabilir hale getirebilirsiniz. Daha fazla bilgi için şu makalelere bakın:

  • olağanüstü durum kurtarma ve hesap yük devretme Azure Blob Depolama
  • Azure Event Hubs coğrafi olağanüstü durum kurtarma

Sonraki adımlar

• Güvenilir Azure uygulamaları tasarlama
• Belirli Azure hizmetleri için dayanıklılık denetim listesi
• Azure'da dayanıklılık için veri yönetimi
• Azure uygulamaları için yedekleme ve olağanüstü durum kurtarma
• Bölge genelinde hizmet kesintisinden kurtarma
• Azure hizmetleri için Microsoft Hizmet Düzeyi Sözleşmeleri (SLA)