Yük devretme ve yeniden çalışma nedir?

Bu makalede hem yük devretme hem deyeniden çalışma işleminin bulut ortamında nasıl çalıştığına genel bir genel bakış sağlanmaktadır. Ancak yük devretmeyi anlamak için önce yedekliliği ve çoğaltmayı anlamanız gerekir. Bu makaleye devam etmeden önce bu kavramlar hakkında bilgi edinmek için bkz. Yedeklilik, çoğaltma ve yedekleme.

Hem uygulamaların hem de veri çoğaltmalarının yedekli kopyalarını korumanın yaygın nedenlerinden biri yük devretme gerçekleştirebilmektir. Yük devretme ile, iyi durumda olmayan örneklerden gelen trafiği ve istekleri sağlıklı örneklere yönlendirebilirsiniz. Ardından, özgün örnekler yeniden iyi duruma geldikten sonra, özgün yapılandırmaya geri dönmek için bir geri yükleme gerçekleştirebilirsiniz.

Etkin ve pasif örnek rolleri

Yük devretme bağlamında örnek , veritabanı gibi tek bir bileşen veya bir bölgede hizmet dağıtımını oluşturan birden çok bileşenden oluşan bir koleksiyon olabilir. Çözümün tamamında, çözümün farklı bölümlerini farklı şekillerde ve farklı durumlarda devredebilirsiniz.

Yük devretme ve yeniden çalışma için yapılandırılmış bileşenlerden oluşan bir bileşen veya koleksiyon birden çok örnek gerektirir. Bu örneklerin her biri belirli bir rolü varsayar:

• Birincil veya etkin örnekler, istemcilerden gelen istekleri sunma gibi etkin bir şekilde çalışır. Genellikle bir kerede bir birincil örnek vardır.
• İkincil veya pasif örnekler etkin değildir, ancak gerekirse birincil duruma geçmeye hazırdır. Birkaç ikincil örnek olabilir.

Pasif örnekleri yapılandırmanın çeşitli yolları vardır. Her yol, kurtarma süresi ile maliyet ve operasyonel karmaşıklık gibi diğer faktörler arasındaki dengeleri içerir:

• Her zaman üretim trafiğini kabul etmeye hazır olacak şekilde tasarlanmış sıcak yedekler.
• Üretim trafiğini kabul etmeye neredeyse hazır olacak şekilde tasarlanan ancak trafiği kabul etmeden önce bazı yapılandırma değişiklikleri veya ölçeklendirme işlemlerinin tamamlanması gerekebilecek sıcak beklemeler.
• Minimum bir yapılandırmada kısmen dağıtılan ve üretim trafiğini kabul edebilmesi için önemli hazırlıkların tamamlanmasına ihtiyaç duyan pilot ışık yedekleri.
• Üretim trafiğini kabul etmeden önce dağıtılacak bileşenlere güvenen ve belki de hiç kullanılmayan soğuk beklemeler.

Tavsiye

Bazı çözümler etkin-etkin bir yaklaşım kullanacak şekilde oluşturulur ve bu da birden çok örneğin isteklere hizmet ettiği anlamına gelir. Etkin-etkin bir sistem, tüm örnekler her zaman etkin olarak istekleri karşıladığı için yük devretme gerektirmez.

Yük devretme kapsamları

Farklı durumlar farklı yük devretme stratejileri gerektirir. Bu olası stratejileri göstermek için, veritabanından verilere erişen bir uygulamadan oluşan örnek bir çözümü göz önünde bulundurun. Uygulama sunucunuzun yedek kopyalarını ve veritabanının birden çok çoğaltmasını oluşturarak çözümü yük devretme için yapılandırabilirsiniz. Ardından şunları yapılandıracaksınız:

• Azure bölgesindeki farklı kullanılabilirlik alanlarına kopya ve çoğaltmaları yerleştirerek zon yedekliliği sağlama.
• Bölgeler arasında yük devretmek için global yük dengeleyici kullanarak coğrafi yedeklilik.

Normal işlemlerdeki genel mimariyi gösteren basitleştirilmiş bir diyagram aşağıdadır:

Farklı durumlar bu çözümde farklı yük devretme olaylarını tetikleyebilir. Bunların her biri, yük devretme yapan bileşenlerin detay seviyesini temsil eden bir yük devretme kapsamına karşılık gelir.

• Aktif veritabanı çoğaltması kullanılamaz hale geldiğinde, veritabanı çoğaltmasının yük devretmesi meydana gelebilir. Pasif kopya, aktif kopya olacak şekilde terfi ettirilir. Genellikle, uygulamalar isteklerini yeni aktif kopyaya hızla yönlendirebilir.

  

• Bir kullanılabilirlik alanı yük devretmesi, tam bir kullanılabilirlik alanı kesintisi yaşandığında meydana gelebilir. Bu tür bir kesinti, tüm trafiğin kalan bölgedeki web sunucusuna yönlendirilmesini gerektirir ve ayrıca şu anda mevcut değilse, hayatta kalan bölgedeki veritabanı çoğaltmasının etkin çoğaltmaya dönüşmesini sağlar:

  

• Azure birincil bölgesinin tamamında yıkıcı bir kayıp olması durumunda bir bölge yük devretmesi gerçekleşebilir.

  

Bu kapsamların her biri bir yük devretme türü sağlarken, ayrı yük devretme gereksinimleri ve işlemleri olabilir. Ayrıca, alanlar arası yedekli hizmetleri kullandığınızda olduğu gibi bazı yük devretme kapsamlarından Microsoft sorumlu olabilirken, Azure bölgeleri arasında yük devretme gibi daha geniş kapsamlarda yük devretmeden sorumlu olabilirsiniz.

Yük devretme ve iş sürekliliği planlaması

İş sürekliliği planlamasının bir parçası, yük devretme stratejilerinizi tasarlamak ve yük devretme yapabileceğiniz farklı senaryoları belirlemektir.

Genel olarak, iş sürekliliği planlarınızın kullanılabilirlik alanları içinde veya arasında otomatik yük devretme yordamları içermesi gerekir. Bu yük devretme türü, yüksek kullanılabilirlik stratejinizin bir parçasını oluşturur. Örneğin, bir veritabanının etkin çoğaltması başarısız olursa, otomatik bir işlem pasif çoğaltmayı etkin çoğaltma olacak şekilde yükseltebilir. Ardından, web sunucuları yeni aktif replika ile iletişim kurar. Benzer şekilde, kullanılabilirlik alanı başarısız olursa, kalan bölgeler kullanılarak otomatik olarak kurtarılması için birçok çözüm oluşturulur.

Olağanüstü durum senaryoları için, örneğin tam bir bölge kesintisi gibi olası olmayan durumlarda kullanılmak üzere farklı yük devretme yordamları uygulanır. Bölge kesintisi durumunda, gelen web isteklerini ikinci bölgeye yönlendirebilir ve veritabanının ikincil bölgedeki bir çoğaltmaya yük devretmesini tetikleyebilirsiniz.

yük devretme yordamlarını iş sürekliliği planlamanıza dahil etmek için daha ayrıntılı tasarım ve test yapmanızı gerektirdiğini unutmayın. Daha fazla bilgi için bkz. İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma nedir?

Planlı ve plansız yük devretmeler

Planlanmamış yük devretmeler , bir bileşenin kesintisi sırasında gerçekleştirilen yük devretmelerdir, böylece hizmeti başka bir örnek kullanarak geri yükleyebilirsiniz. Planlanmamış yük devretmeler, bazen bir çözümün tasarımına bağlı olarak kapalı kalma süresine veya veri kaybına neden olabilir. Planlanmamış yük devretme işlemleri, hatayı algılamak ve yük devretmenin ne zaman tetiklendiğine karar vermek için bir şey gerektirir.

Buna karşılık, planlı yük devretmeler sizin proaktif olarak başlattığınız durumlardır. Bunu, düzeltme eki uygulanmış ve yeniden başlatılacak bir sanal makine gibi bir şey olmasını tahmin ederek yapabilirsiniz. Planlı yük devretme işlemleri, normal bakım yordamlarının bir parçası olduğundan kapalı kalma süresi ve veri kaybı için daha düşük toleransa sahip olabilir.

Yük devretme nasıl çalışır?

Yük devretme genellikle el ile veya otomatik bir sistem tarafından gerçekleştirilebilecek aşağıdaki adımlardan oluşur. Bu adımların her biri için belirli ayrıntılar belirli sisteme bağlıdır.

1. Bir hatayı algılama (yalnızca planlanmamış yük devretmeler). Otomatik yük devretme için bir örneğin kullanılamaz durumda olduğunu algılayan bir şey olması gerekir. Bu durum genellikle bir tür sistem durumu denetimine dayanır. Farklı hizmetler, sağlıklarını farklı şekillerde tanımlar. Örneğin, bazı hizmetler örnekler arasında proaktif olarak heartbeat olayları gönderir. Diğerleri her örneği düzenli aralıklarla araştırmak için ayrı bir bileşen gerektirir. Sistem durumu izleyicilerinin bir örneğin başarısız olduğunu algılaması genellikle biraz zaman alır ve örneğin yalnızca meşgul olması ve yanıt verememesi durumunda yetkisiz kullanım süresi verilmesi genellikle önemlidir.

2. Hata durumunda devretmeyi seçin. Bir noktada yük devretme gerçekleştirme kararı alınacaktır. Karar otomatik bir araç tarafından veya el ile yapılabilir. Kuruluşunuzun risk toleransı bu kararın ne kadar hızlı alınabileceğini etkileyebilir. Risk toleransı düşükse, bir sorun belirtisi varsa hızlı bir şekilde yük devretmeyi tercih edebilirsiniz. Eğer daha yüksek bir risk toleransınız varsa, sorunun çözülüp çözülemediğini görmek için beklemeyi tercih edebilirsiniz.

3. Yeni bir birincil örnek seçin. Kalan örneklerden biri yeni birincil hale gelmelidir.

   Bazı durumlarda, yeni birincil olacak örneği önceden tanımlamış olabilirsiniz veya geçilecek tek bir örneğiniz olabilir.

   Diğer durumlarda, sistemin yeni bir birincil örneği seçtiği otomatik bir işlem vardır. Lider seçimi de dahil olmak üzere dağıtılmış bilgi işlemde kullanılan bir dizi konsensüs algoritması vardır. Bu algoritmalar veritabanları gibi ilgili hizmetler içinde uygulanır. Bazı sistemlerde her örneğin yeni birincil çoğaltmadan haberdar edilmesi önemlidir ve bu nedenle seçimin sonuçları her çoğaltmaya otomatik olarak duyurulur.

4. İstekleri yeniden yönlendirme. İsteklerin iyi durumdaki örneklere veya yeni birincil örneğe yönlendirilmesi için ortamınızı yapılandırın.

   Bunu başarmak için, isteklerin nereye gönderileceğine ilişkin diğer sistemleri güncelleştirmeniz gerekebilir. Bu, iyi durumda olmayan örneği dışlamak için bir yük dengeleme sisteminin güncelleştirilmesini içerebilir. Diğer durumlarda, etki alanı adı sistemi (DNS) genellikle sistemin etkin bir örneğine istek göndermenin bir yolu olarak kullanılır. Yük devretme işleminin bir parçası olarak, isteklerin yeni birincil örneğe yönlendirilmiş olması için DNS kayıtlarını güncelleştirmeniz gerekir. DNS, istemcilere güncelleştirilmiş DNS kayıtlarını ne sıklıkta denetlemeleri gerektiğini gösteren yaşam süresi (TTL) kavramına sahiptir. TTL'iniz uzun bir değere ayarlanırsa, istemcilerin yük devretme hakkında bilgi alması zaman alabilir ve eski birincile istek göndermeye devam edebilirler.

Yük devretme işlemlerinde gecikmeler olabileceği için, kapalı kalma süresine (RTO hedefiniz) ve veri kaybına (RPO hedefiniz) yönelik gereksinimlerinizi karşılayacak şekilde yük devretme prosedürlerinizi planlamanız önemlidir. Daha fazla bilgi edinmek için bkz. İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma nedir?

Geri dönüş

Yeniden çalışma , trafiği yeniden başlatma ve özgün birincil örneğe yeniden yönlendirme işlemidir.

Bazı durumlarda geri çekilmeye hiç gerek yoktur, çünkü her örnek, birincil olarak hareket etme kapasitesine eşit derecede sahiptir. Ancak, uygulamalarınızı belirli bir Azure bölgesinden çalıştırmanız gerektiği ve bölgesel bir kesinti sırasında geçici olarak başka bir bölgeye yük devretmiş olmanız gibi, yeniden çalışmanın önemli olduğu bazı durumlar vardır.

Bazen yeniden çalışma, yük devretme ile aynı şekilde işlenir. Ancak, çeşitli nedenlerden dolayı geri yükleme, yük devretmeden daha karmaşık olabilir.

• Veri eşitleme sorunları. Normal yük devretme sırasında ve sonrasında bile, önceki birincil örnek hala bazı çalışmalar yapmış veya veri deposuna veri yazmış olabilir. Yeniden çalışma işleminin bir parçası, birincil ve ikincil örnekler arasındaki çakışmaları veya yinelemeleri yönetmek de dahil olmak üzere çözümünüz genelinde veri tutarlılığını ve bütünlüğünü sağlamaktır.

  Veri eşitleme sorunlarının el ile müdahale gerektirmesi yaygın olarak görülür. Çakışan verilere ihtiyacınız yoksa veritabanını veya başka bir durumu sıfırlamayı seçebilirsiniz.

• Düzeltme adımları. Yük devretme öncesinde birincil üzerinde iyileştirme adımları denendiyse, bu birincil sunucuyu bilinmeyen bir durumda bırakmış olabilir.

  Birincil örneğin tutarsız bir durumda olma riski varsa, geriye dönmeden önce bilinen iyi bir durumda olması için birincil örneği yok etmeniz ve yeniden dağıtmanız gerekebilir.

• Ekstra kapalı kalma süresi. Yeniden yapılandırmalar veya veri tutarlılığını geri yükleme işlemleri nedeniyle yeniden çalışma işlemi sırasındaki kapalı kalma süresi, yük devretme sırasından daha uzun olabilir.

  Bakım penceresi sırasında yeniden çalışma işlemlerini çalıştırarak veya kullanıcılara değişikliği önceden bildirerek bu sorunu giderebilirsiniz. Ayrıca, sistem çevrimiçiyken hazırlık işlemlerinin bazılarını gerçekleştirebilir ve gerekli kapalı kalma süresini en aza indirebilirsiniz.

• Risk toleransı. Başarısızlık geçişi bir kesinti nedeniyle oluştuysa, kuruluşun kesinti veya geri dönüş sırasındaki diğer risklere karşı toleransı daha düşük olabilir.

  İş paydaşları süreç boyunca durumdan haberdar edilmeli ve geri dönüş gereksinimi ile geri dönüş prosedürlerinin sonuçları hakkında tam olarak bilgilendirilmelidir. Değişiklikleri yapmak için uygun bir zaman anlaşması yapabilirsiniz.

Azure hizmetlerinde yük devretme ve geri yükleme

Yük devretmenin genel olarak nasıl çalıştığını anlamak önemli olsa da, her Azure hizmetinin yük devretmeye ve yeniden çalışmaya farklı yaklaşabileceğini unutmayın. Belirli Azure hizmetlerinin güvenilirlik açısından nasıl çalıştığı hakkında bilgi için her hizmetin güvenilirlik kılavuzuna bakın.

Birçok Azure hizmeti belirli yük devretme türlerini otomatik olarak işler. Örneğin, alanlar arası yedekli olacak şekilde yapılandırılmış Azure hizmetlerini kullandığınızda, Microsoft sizin için otomatik olarak kullanılabilirlik alanları arasında yük devretme gerçekleştirir. Daha fazla bilgi edinmek için bkz. Kullanılabilirlik alanları nelerdir? ve Azure hizmeti güvenilirlik kılavuzları.

Sanal makineleri kullanıyorsanız , Azure Site Recovery sanal makineleri ve disklerini kullanılabilirlik alanları arasında veya başka bir Azure bölgesine çoğaltır ve sizin için yük devretme gerçekleştirebilir.

Birden çok Azure hizmetini birleştiren kendi çözümünüzü tasarladığınızda yük devretme gereksinimleriniz daha karmaşık hale gelebilir. Uygulama katmanı ve veritabanı ile bir çözüm tasarladığınızı ve çok bölgeli etkin/pasif mimari oluşturmak istediğinizi varsayalım. Birincil bölgedeki bir kesinti sırasında uygulamanızın ve veritabanınızın ikincil bölgeye birlikte yük devretmesi önemlidir. Tam olarak kullandığınız hizmetlere bağlı olarak, her bölgedeki dağıtımlar arasında geçiş yapmak için kendi yük devretme yaklaşımınızı planlamanız gerekebilir. Azure, Azure Front Door ve Azure Traffic Manager aracılığıyla genel trafik yönlendirme ve yük dengeleme sağlar ve yük devretme gereksinimlerinizi karşılayan teknolojiyi seçebilirsiniz. Her hizmet, uygulamanızın her bölgesel örneğinin sistem durumunu izlemeyi destekler ve trafiği sağlıklı örneğe otomatik olarak yeniden yönlendirecek şekilde yapılandırabilirsiniz.

Sonraki adımlar

• Güvenilirlikle ilgili paylaşılan sorumluluk hakkında bilgi edinin.
• Azure Well-Architected Framework'te yüksek oranda kullanılabilir çok bölgeli tasarım önerileri hakkında bilgi edinin.