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 yedek kopyalarını tutmanın yaygın nedenlerinden biri failover 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 sağlıklı duruma geldikten sonra, özgün yapılandırmaya dönmek için bir geri dönüş 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:

• Tasarımı gereği her zaman üretim trafiğini kabul etmeye hazır olan 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.
• Tamamlanlamadan önce önemli hazırlıklar gerektiren ve kısmen asgari bir yapılandırmada dağıtılan pilot ışık bekleme sistemleri, üretim trafiğini kabul edemez.
• Hiç dağıtılmayan ve üretim trafiğini kabul etmeden önce dağıtılacak bileşenlere güvenen soğuk beklemeler.

Tavsiye

Bazı çözümler aktif-aktif bir yaklaşım kullanacak şekilde oluşturulur ve bu da birden çok örneğin isteklere hizmet ettiği anlamına gelir. Tüm örnekler her zaman aktif olarak talepleri karşıladığından, aktif-aktif bir sistem 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ölgesi içindeki farklı kullanılabilirlik bölgelerine kopyaları ve çoğaltmaları yerleştirerek bölge yedekliliği sağlama.
• Bölgeler arasında hata durumlarında geçiş yapmak için küresel bir yük dengeleyici kullanarak coğrafi yedeklilik sağlama.

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 devreden bileşenlerin detay seviyesini temsil eden bir yük devretme kapsamına karşılık gelir.

• Veritabanı çoğaltması yük devretmesi, etkin veritabanı çoğaltması kullanılamaz olduğunda meydana gelebilir. Pasif kopya, etkin kopya olacak şekilde terfi ettirilir. Genellikle, uygulamalar isteklerini yeni aktif yedeğe hızla yeniden yönlendirebilir.

  

• Tam kullanılabilirlik alanında kesinti yaşandığında kullanılabilirlik alanı yük devretmesi oluşabilir. Bu tür bir kesinti, tüm trafiğin kalan bölgedeki web sunucusuna yönlendirilmesini gerektirir ve hayatta kalan bölgedeki veritabanı çoğaltmasının henüz değilse aktif çoğaltma haline gelmesini sağlar.

  

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

  

Bu kapsamların her biri bir yük devretme mekanizması sağlarken, farklı 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 yapabileceğiniz farklı kapsamlar da dahil olmak üzere yük devretme stratejilerinizi tasarlamaktır.

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 etkin replikayla bağlantı 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 kesintisinin nadir görüleceği durumlarda, farklı yük devretme prosedürleri kullanılır. Bölge arızası durumunda, gelen web isteklerini ikinci bölgeyi kullanacak şekilde yönlendirebilir ve veritabanının ikincil bölgedeki bir replikaya 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 nasıl tasarlandığına bağlı olarak kesinti 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, proaktif olarak tetiklediğiniz planlı yük devretmelerdir. 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.

Hata durumu yönetimi nasıl çalışır?

Kesintisiz geçiş genellikle el ile veya otomatik bir sistem tarafından gerçekleştirilebilen 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 bir yük devretme, bir örneğin kullanılamaz hale geldiğini algılayan bir sistemin varlığını gerektirir ve bu algılama genellikle bir tür sağlık kontrolüne dayanır. Farklı hizmetler, sağlıklarını farklı şekillerde tanımlar. Örneğin, bazı hizmetler örnekler arasında proaktif olarak sinyal 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 tespit etmesi genellikle biraz zaman alır ve örneğin sadece meşgul olması ve yanıt verememesi durumu için hoşgörü süresi tanımak genellikle önemlidir.

2. Yük devretmeyi seçin. Belirli bir aşamada 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. Riske karşı düşük toleransınız varsa, herhangi bir sorun belirtisi olduğunda hızlı bir şekilde yük devretmeyi tercih edebilirsiniz. Daha yüksek bir risk toleransınız varsa, yük devretmeden önce 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 olmalıdır.

   Bazı durumlarda, hangi örneğin yeni birincil olması gerektiğini önceden belirlemiş olabilirsiniz veya geçiş yapabileceğiniz sadece bir örnek 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 replikadan haberdar edilmesi önemlidir ve bu yüzden seçim sonuçları her replikaya 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'niz uzun bir değere ayarlanırsa, istemcilerin yük devretme hakkında bilgi alması zaman alabilir ve eski birincil sunucuya istek göndermeye devam edebilir.

Yük devretme işlemleri gecikmeler içerebileceğinden, yük devretme yordamlarınızı kapalı kalma süresi (kurtarma noktası hedefiniz veya RTO) ve veri kaybı (kurtarma noktası hedefiniz veya RPO) gereksinimlerinizi karşılayacak şekilde planlamanız önemlidir. Daha fazla bilgi edinmek için bkz. İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma nedir?

Failback

Failback, trafiği eski birincil örneğe geri yükleme ve yeniden yönlendirme işlemidir.

Bazı durumlarda, her bir örnek birincil olarak eşit derecede işlev görebildiği için hiç geri dönmek gerekmez. 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ş olduğunuz durumlar gibi, eski duruma geri dönmenin önemli olduğu bazı durumlar vardır.

Bazen geri dönüş, yük devretme ile aynı şekilde gerçekleştirilir. Ancak, çeşitli nedenlerle yeniden çalışma, 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 gerçekleşmeden önce birincil sunucu örneğinde herhangi bir iyileştirme adımı denendiyse, bu adımlar birincil sunucu örneğini bilinmeyen bir durumda bırakmış olabilir.

  Birincil örneğin tutarsız bir durumda olma riski varsa, geri döndürmeden önce bilinen doğru bir durumda olması için birincil örneği yok etmeniz ve yeniden dağıtmanız gerekebilir.

• Ek 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ı. Yük devretme bir kesinti nedeniyle oluştuysa, kuruluşun kapalı kalma süresine veya yeniden çalışma sırasındaki diğer risklere dayanıklılığı daha düşük olabilir.

  İş paydaşları süreç boyunca durumdan haberdar edilmeli ve geri dönüş ihtiyacı 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.