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ızla geri yükleyebilmeniz ve iş sürekliliğini (BC) sürdürmek için işlemlerin çalışmaya devam edebilmesi 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. Bir iş sürekliliği ve olağanüstü durum kurtarma (BCDR) çözümünü hazır hale getirmeniz sayesinde kuruluşunuz veya kuruluşunuz kesintilere daha hızlı yanıt verebilir, planlı veya plansız olabilir 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 kod miktarını 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 dikkate aldığınızdan 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.

• Azure sanal ağındaki yalıtılmış logic Apps çalışma zamanı örneğinde çalışan mantıksal uygulamalar oluşturduğunuz tümleştirme hizmeti ortamları (ISE'ler). Bu mantıksal uygulamalar daha sonra bu sanal ağdaki bir güvenlik duvarının arkasında korunan kaynaklara erişebilir.

Birincil ve ikincil konumlar

Her mantıksal uygulamanın dağıtım için kullanmak istediğiniz konumu belirtmesi gerekir. Bu konum, genel çok kiracılı Azure'da "Batı ABD" gibi genel bir bölge veya daha önce oluşturup bir Azure sanal ağına dağıttığınız bir tümleştirme hizmeti ortamıdır (ISE). Mantıksal uygulamaları ISE'de çalıştırmak, mantıksal uygulamaları genel bir Azure bölgesinde çalıştırmaya benzer ve bu da olağanüstü durum kurtarma stratejinizin her iki senaryoya da uygulanabileceği anlamına gelir. Ancak, ISE'lerin yalnızca ISE'ler tarafından kullanılabilen kaynaklara erişimi yapılandırma gibi başka konuları vardır.

Not

Mantıksal uygulamanız bir tümleştirme hesabında depolanan ticari ortaklar, anlaşmalar, şemalar, haritalar ve sertifikalar gibi B2B yapıtlarıyla da çalışıyorsa, hem tümleştirme hesabınızın hem de mantıksal uygulamalarınızın aynı konumu 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 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şarsa, 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 her dağıtım hedefi için kullanılacak yapılandırma değerlerini sağlamak üzere parametre dosyalarını kullanma 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 veya ISE'lere 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 genel çok kiracılı Azure'daki bölgelere dağıtılır veya her iki örnek de ISE'lere dağıtılır ve bu sayede mantıksal uygulamalarınız bir Azure sanal ağındaki kaynaklara doğrudan erişebilir. BCDR için eşleştirilmiş bölgeler hakkında en iyi yöntemler ve daha fazla bilgi için bkz. Azure'da bölgeler arası çoğaltma: İş sürekliliği ve olağanüstü durum kurtarma.

  Örneğin, birincil mantıksal uygulama bir ISE içinde çalıştırıldığında ve ISE sürümü bağlayıcılar, Azure sanal ağındaki kaynakları çağırmak için HTTP eylemleri veya her ikisini de kullandığında hem birincil hem de ikincil konumlar ISE olmalıdır. Bu senaryoda, ikincil mantıksal uygulamanızın ikincil konumda da birincil mantıksal uygulamayla benzer bir kurulumu olmalıdır.

  Not

  Daha gelişmiş senaryolar için hem çok kiracılı Azure'ı hem de konum olarak ISE'yi birlikte kullanabilirsiniz. Ancak mantıksal uygulamaların ISE ile çok kiracılı Azure'da nasıl çalıştığı arasındaki farkları dikkate aldığınızdan ve anladığınızdan emin olun.

• ISE'leri kullanıyorsanız ölçeğin genişletildiğinden veya yükü işlemek için yeterli kapasiteye sahip olduklarından emin olun .

Ö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:

Örnek: Tümleştirme hizmeti ortamı

Bu örnek, önceki birincil ve ikincil mantıksal uygulama örneklerini gösterir ancak ayrı ISE'lere dağıtılır. Tek bir Resource Manager şablonu hem mantıksal uygulama örneklerini, bu mantıksal uygulamaların gerektirdiği bağımlı kaynakları hem de dağıtım konumları olarak ISE'leri tanımlar. Ayrı parametre dosyaları, her konumda dağıtım için kullanılacak yapılandırma değerlerini tanımlar:

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 hale 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 büyük olasılıkla kullanılamaz. Bu durumda, ikincil örneğinizin çoğaltılmış veya yedek bir veritabanı ve bu veritabanıyla 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 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 .

Not

Mantıksal uygulamanız bir tümleştirme hizmeti ortamında (ISE) çalışıyorsa ve şirket içi veri kaynakları için yalnızca ISE sürümüne sahip bağlayıcılar kullanıyorsa, ISE bağlayıcıları şirket içi kaynağa doğrudan erişim sağladığından veri ağ geçidine ihtiyacınız yoktur.

İstediğiniz şirket içi kaynak için ISE sürümüne sahip bağlayıcı yoksa mantıksal uygulamanız, ISE'nizde değil genel çok kiracılı Azure'da çalışan ISE olmayan bir bağlayıcı kullanarak bağlantıyı oluşturmaya devam edebilir. Ancak bu bağlantı için şirket içi veri ağ geçidi gerekir.

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

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

Birincil-ikincil rol	Açıklama
Etkin-etkin	Her iki konumdaki birincil ve ikincil mantıksal uygulama örnekleri şu desenlerden birini izleyerek istekleri etkin bir şekilde işler: - Yük dengeleme: Her iki örneğin de bir uç noktayı dinlemesini ve gerektiğinde her örneğe yönelik trafiğin yük dengelemesini sağlayabilirsiniz. - Rakip tüketiciler: Her iki örneğin de bir kuyruktan gelen iletiler için rekabet edebilmesi için rakip tüketiciler gibi davranmasını sağlayabilirsiniz. Bir örnek başarısız olursa, diğer örnek iş yükünü devralır.
Aktif-pasif	Birincil mantıksal uygulama örneği tüm iş yükünü etkin bir şekilde işlerken ikincil örnek pasiftir (devre dışı veya etkin değildir). İkincil, kesinti veya hata nedeniyle birincilin kullanılamadığını veya çalışmadığını belirten bir sinyal bekler ve etkin örnek olarak iş yükünü devralır.
Kombinasyon	Bazı mantıksal uygulamalar etkin-etkin bir rol oynarken, diğer mantıksal uygulamalar etkin-pasif bir rol oynar.

Etkin-etkin örnekleri

Bu örnekler, her iki mantıksal uygulama örneğinin de istekleri veya iletileri etkin bir şekilde 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 donanım parçası gibi bir "fiziksel" 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 örnekte öncelikle Azure Load Balancer gösterse de senaryonuzun gereksinimlerine en uygun seçeneği kullanabilirsiniz:

  

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

  

Aktif-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 kullanıcı 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, ikincil konumda ise etkin-pasif mantıksal uygulama örneklerine sahip olduğ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 bir Azure Service Bus kuyruğu dinlerken, başka bir etkin mantıksal uygulama Office 365 Outlook yoklama tetikleyicisini kullanarak e-postaları denetler.

• İkincil konumda etkin bir mantıksal uygulama, aynı Service Bus kuyruğundan gelen iletileri dinleyerek ve bunlarla rekabet ederek birincil konumdaki mantıksal uygulamayla çalışır. Bu arada pasif etkin olmayan bir mantıksal uygulama, birincil konum kullanılamaz hale 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şlatıldığı 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.

Bırakılan 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:

• Yönlendirme notu deseni düzeltildi

  Bir iş sürecini daha küçük aşamalara ayıran bu kurumsal ileti düzeni. Her aşama için, bu aşamanın 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 mantıksal uygulama örneğinde takılmış olabilecek iş süreçlerinin sayısını azaltırsınız. Bu desen hakkında daha 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 rolleri ayarlayarak rakip tüketici desenini uygulayabilirsiniz.

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

• Zaman aşımı düzeni olmadan peek-lock

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; bu da bu geçmişi farklı bir konuma geçiremezsiniz. Birincil örneğiniz ikincil örneğe yük devrederse, yalnızca 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 konumdan bağımsız bilgiler 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 zamanlamayı temel alır ve başka ölçüt oluşturmaz, örneğin:

• Sabit bir sıklık ve aralık, örneğin her 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 tetikleyicisiyle 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üklemek için hedef süreyi ifade eden kurtarma süresi hedefini (RTO) azaltmak için mantıksal uygulama örneklerinizi etkin-pasif rollerin ve pasif-etkin rollerin bir bileşimiyle ayarlayabilirsiniz. Bu kurulumda zamanlamayı konumlar arasında bölersiniz.

Örneğin, her 10 dakikada bir çalıştırılması gereken bir mantıksal uygulamanız olduğunu varsayalım. Mantıksal uygulamalarınızı ve konumlarınızı, birincil konum kullanılamaz duruma gelirse ikincil konumun işi üstleyebilecek şekilde ayarlayabilirsiniz:

• 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'i ayarlayın:

  • Pasif devre dışı mantıksal uygulama için, Yinelenme tetikleyicisini birincil konumdaki etkin mantıksal uygulamayla aynı zamanlamaya ayarlayın. Bu, saatin en üstündedir ve 09: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 sağlanıp sağlanmadığı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. Hizmetin veya uç noktanın sağladığı veriler şu türlerden 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ı kullanır.

  Örneğin, veritabanından bir 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 FALSETRUEdeğiştirerek isRead bu satırı güncelleştirir.

  Bu sunucu tarafı yaklaşımı Service Bus kuyruklarında veya mantıksal uygulama iletiyi işlerken tetikleyicinin iletiyi okuyup kilitleyebildiği kuyruğa alma semantiğine sahip konular 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. Belirli bir anda yalnızca bir konumda etkin bir mantıksal uygulama örneği olabilir. Birincil örnek alternatif konuma yük 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üketiciler olarak çalıştıkları etkin-etkin rolleri veya alternatif örneğin birincil örneğin alternatif konuma yük devretmesini 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 kilitleri korur.

  Not

  Mantıksal uygulamanızın iletileri örneğin Service Bus kuyruğundan belirli bir sırada 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 bu özellikleri sağlamak için kullanılır:

• Mantıksal uygulamanız için başkalarının çağırabileceği doğrudan bir REST API

  Örneğin, diğer mantıksal uygulamaların iş 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 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

Mantıksal uygulama herhangi bir iş yapmadığından ve başka bir hizmet veya sistem tetikleyiciyi açıkça çağırana kadar beklediğinden, olağanüstü durum kurtarma açısından İ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şi işlerken, ikincil örnek birincil deneyim kesintiye veya hataya 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 özelliği 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ği için etkin-pasif rolleri yürütmek için web kancası tetikleyicilerini 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 temel olarak kullanabileceğiniz bir çözüm açıklanmaktadır. Bu çözüm için üst düzey görsele genel bakış aşağıdadır:

Birincil örnek kullanılabilirliğini denetleme

Birincil örneğin kullanılabilir, çalışıyor ve çalışabilir olup olmadığını belirlemek için, birincil örnekle aynı konumda bir "sistem durumu denetimi" mantıksal uygulaması oluşturabilirsiniz. Daha sonra bu durum denetimi uygulamasını alternatif bir konumdan çağırabilirsiniz. Sistem durumu denetimi uygulaması başarıyla yanıt verirse, o bölgedeki Azure Logic Apps hizmeti için temel alınan 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ıtlayın.

   Önemli

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

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şim kuran diğer tüm hizmetlerin durumunu dikkate alabilirsiniz. Bu diğer hizmetlerin durumunu da değerlendirmek için sistem durumu denetimi mantıksal uygulamasını genişletmesi gerekir.

İzleme 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 "watchdog" mantıksal uygulaması oluşturun. Örneğin, watchdog mantıksal uygulamasını, sistem durumu denetimi mantığının çağrılması başarısız olursa, izleyicinin hata ve birincil örneğin neden yanıt vermediğini araştırabilmesi için operasyon ekibinize bir uyarı gönderebilmesi için ayarlayabilirsiniz.

Önemli

İzleme mantıksal uygulamanızın birincil konumdan farklı bir konumda olduğundan emin olun. Birincil konumdaki Azure Logic Apps sorunlarla karşılaşıyorsa watchdog mantıksal uygulama iş akışınız çalışmayabilir.

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 izleme mantıksal uygulaması 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 meydana geldikten sonra bu etkinleştirme mantıksal uygulamasını çağırmak için izleme uygulamanızı 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ölgeler arasında dağıtır. Bu özellik, dayanıklı mimarileri etkinleştirmek ve bir bölgede veri merkezi hataları olması durumunda 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:

• Tüketim mantığı uygulamalarını bölge yedekliliği ve kullanılabilirlik alanlarıyla 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 elde edilen tanılama verilerini daha fazla işleme ve işleme için 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ı ayarlayıp verileri birden çok Log Analytics çalışma alanına göndererek verileri hem birincil hem de ikincil konumlarda kullanılabilir hale getirebilirsiniz. Daha fazla bilgi için bkz. Azure İzleyici günlüklerini ayarlama ve Azure Logic Apps için tanılama verileri toplama.

• Verileri Azure Depolama'ya veya Azure Event Hubs göndermek istiyorsanız coğrafi 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
  • Coğrafi olağanüstü durum kurtarmayı Azure Event Hubs

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)