Amazon Açık Arama Hizmeti yeni tanıttı Beklemede Multi-AZİşletmelere kritik iş yükleri için gelişmiş kullanılabilirlik ve tutarlı performans sağlamak üzere tasarlanmış bir dağıtım seçeneği. Bu özellik sayesinde, yönetilen kümeler bölgesel altyapı arızalarına karşı dirençli kalırken %99.99 kullanılabilirliğe ulaşabilir.

Bu yazıda, Bekleme Özellikli Multi-AZ ile arama ve dizin oluşturmanın nasıl çalıştığını keşfediyor ve güvenilirliğine, basitliğine ve hata toleransına katkıda bulunan temel mekanizmaları inceliyoruz.

Olayın Arka Planı

Bekleme özellikli Multi-AZ, OpenSearch Hizmeti etki alanı örneklerini, ikisi aktif ve biri yedek olarak belirlenmiş olmak üzere üç Erişilebilirlik Alanında dağıtır. Bu yapılandırma, tüm bölgelerde aynı kapasiteyi koruyarak bölgesel arızalar durumunda bile tutarlı performans sağlar. Daha da önemlisi, bu bekleme bölgesi bir statik olarak kararlı tasarımArızalar sırasında kapasite sağlama veya veri taşıma ihtiyacını ortadan kaldırır.

Normal işlemler sırasında aktif bölge, hem okuma hem de yazma istekleri için koordinatör trafiğinin yanı sıra parça sorgusu trafiğini de yönetir. Bekleme bölgesi ise yalnızca çoğaltma trafiğini alır. OpenSearch Hizmeti, yazma istekleri için senkronize bir çoğaltma protokolü kullanır. Bu, hizmetin bir arıza durumunda (ortalama yük devretme süresi <= 1 dakika) bir bekleme bölgesini derhal aktif duruma yükseltmesine olanak tanır. bölgesel yük devretme. Daha önce aktif olan bölge daha sonra bekleme moduna indirilir ve sağlıklı durumuna geri dönmek için kurtarma işlemleri başlatılır.

Yüksek kullanılabilirliği garanti etmek için arama trafiği yönlendirme ve yük devretme

Bir OpenSearch Hizmeti etki alanında, koordinatör HTTP(S) isteklerini, özellikle indeksleme ve arama isteklerini işleyen herhangi bir düğümdür. Bekleme alanına sahip bir Multi-AZ'de, aktif bölgedeki veri düğümleri, arama istekleri için koordinatör görevi görür.

Bir arama isteğinin sorgulama aşamasında koordinatör, sorgulanacak parçaları belirler ve parça kopyasını barındıran veri düğümüne bir istek gönderir. Sorgu her parçada yerel olarak çalıştırılır ve eşleşen belgeler koordinatör düğüme döndürülür. İsteğin parça kopyalarını içeren düğümlere gönderilmesinden sorumlu olan koordinatör düğüm, süreci iki adımda çalıştırır. İlk olarak, trafiğin parça kopyaları arasında eşit şekilde dağıtılması için düğümlerin bir parça kopyası için sorgulanması gereken sırayı tanımlayan bir yineleyici oluşturur. Daha sonra istek ilgili düğümlere gönderilir.

Parça kopyası için sorgulanacak düğümlerin sıralı bir listesini oluşturmak amacıyla koordinatör düğüm çeşitli algoritmalar kullanır. Bu algoritmalar, dönüşümlü seçimi, uyarlanabilir kopya seçimini, tercihe dayalı parça yönlendirmeyi ve ağırlıklı çevrimsel.

Beklemeli Multi-AZ için parça kopya seçimi için ağırlıklı hepsini bir kez deneme algoritması kullanılır. Bu yaklaşımda, etkin bölgelere 1 ağırlığı, bekleme bölgesine ise 0 ağırlığı atanır. Bu, bekleme Erişilebilirlik Alanındaki veri düğümlerine okuma trafiği gönderilmemesini sağlar.

Ağırlıklar, küme durumu meta verilerinde bir JSON nesnesi olarak depolanır:

"weighted_shard_routing": {
    "awareness": {
        "zone": {
            "us-east-1b": 0,
            "us-east-1d": 1,
            "us-east-1c": 1
         }
     },
     "_version": 3
}

Aşağıdaki ekran görüntüsünde gösterildiği gibi, us-east-1b Bölgenin bölge durumu şu şekildedir: StandByBu Erişilebilirlik Alanındaki veri düğümlerinin bekleme durumunda olduğunu ve yük dengeleyiciden arama veya dizin oluşturma istekleri almadığını belirtir.

Kararlı durum operasyonlarını sürdürmek için, beklemedeki Erişilebilirlik Alanı her 30 dakikada bir döndürülerek tüm ağ parçalarının Erişilebilirlik Alanlarında kapsanması sağlanır. Bu proaktif yaklaşım, okuma yollarının kullanılabilirliğini doğrulayarak olası arızalar sırasında sistemin dayanıklılığını daha da artırır. Aşağıdaki diyagram bu mimariyi göstermektedir.

Önceki diyagramda Bölge-C'nin sıfıra ayarlanmış ağırlıklı bir çevrimsel ağırlığı vardır. Bu, bekleme bölgesindeki veri düğümlerinin herhangi bir indeksleme veya arama trafiği almamasını sağlar. Koordinatör, veri düğümlerini parça kopyaları için sorguladığında, düğümlerin hangi sırayla sorgulanacağına karar vermek için ağırlıklı bir hepsini bir kez deneme ağırlığını kullanır. Beklemedeki Erişilebilirlik Alanının ağırlığı sıfır olduğundan koordinatör istekleri gönderilmez.

Bir OpenSearch Hizmeti kümesinde etkin ve beklemedeki bölgeler, aşağıdaki ekran görüntüsünde gösterildiği gibi Erişilebilirlik Alanı rotasyon ölçümleri kullanılarak istenildiği zaman kontrol edilebilir.

Bölgesel kesintiler sırasında, beklemedeki Erişilebilirlik Alanı, arama istekleri için sorunsuz bir şekilde arıza açma moduna geçer. Bu, etkin Erişilebilirlik Alanında sağlıklı bir parça kopyası mevcut olmadığında, parça sorgusu trafiğinin tüm Erişilebilirlik Alanlarına, hatta beklemede olanlara bile yönlendirildiği anlamına gelir. Bu arıza-açma yaklaşımı, arama taleplerini arızalar sırasında kesintiye karşı koruyarak sürekli hizmet sağlar. Aşağıdaki diyagram bu mimariyi göstermektedir.

Önceki diyagramda, kararlı durum sırasında, parça sorgu trafiği etkin Erişilebilirlik Alanlarındaki (Bölge-A ve Bölge-B) veri düğümüne gönderilir. Bölge-A'daki düğüm arızaları nedeniyle, beklemedeki Erişilebilirlik Alanı (Bölge-C), parça sorgusu trafiğini almak üzere açılamıyor, böylece arama istekleri üzerinde herhangi bir etki olmuyor. Sonunda Bölge-A'nın sağlıksız olduğu algılanır ve okuma yük devretme, beklemeyi Bölge-A'ya geçirir.

Yük devretme, yazma bozukluğu sırasında yüksek kullanılabilirliği nasıl sağlar?

OpenSearch Hizmeti çoğaltma modeli, eşzamanlı doğasıyla karakterize edilen, bir yazma isteğinin kullanıcıya onaylanabilmesinden önce tüm parça kopyalarından onay alınmasının gerekli olduğu bir birincil yedekleme modelini takip eder. Bu çoğaltma modelinin dikkate değer bir dezavantajı, yazma yolunda herhangi bir bozulma olması durumunda yavaşlamaya yatkın olmasıdır. Bu sistemler, arızaları veya gecikmeleri tespit etmek ve ardından bu bilgiyi tüm düğümlere yayınlamak için aktif bir lider düğüme güvenir. Bu sorunları tespit etmek için gereken süre (ortalama tespit süresi) ve daha sonra bunları çözmek (ortalama onarım süresi), büyük ölçüde sistemin bozuk bir durumda ne kadar süre çalışacağını belirler. Ayrıca, bölgeler arası iletişimi etkileyen herhangi bir ağ olayı, çoğaltmanın eşzamanlı doğası nedeniyle yazma isteklerini önemli ölçüde engelleyebilir.

OpenSearch Hizmeti, yazma trafiğini kopyalamak ve seçilmiş bir lider aracılığıyla meta veri güncellemelerini koordine etmek için dahili bir düğümden düğüme iletişim protokolünü kullanır. Sonuç olarak, stres yaşayan bölgeyi beklemeye almak, yazma bozukluğu sorununu etkili bir şekilde çözmeyecektir.

Bölgesel yazma yük devretme: Bölgeler arası çoğaltma trafiğinin kesilmesi

Bekleme Özellikli Multi-AZ için, bölgesel hatalar ve ağ oluşturma olayları gibi öngörülemeyen olaylar sırasında ortaya çıkan potansiyel performans sorunlarını azaltmak için bölgesel yazma yük devretme etkili bir yaklaşımdır. Bu yaklaşım, etkilenen bölgedeki düğümlerin kümeden zarif bir şekilde kaldırılmasını ve bölgeler arasındaki giriş ve çıkış trafiğinin etkili bir şekilde kesilmesini içerir. Bölgeler arası çoğaltma trafiğinin kesilmesiyle, bölge hatalarının etkisi etkilenen bölge içinde kontrol altına alınabilir. Bu, müşteriler için daha öngörülebilir bir deneyim sağlar ve sistemin güvenilir bir şekilde çalışmaya devam etmesini sağlar.

Zarif yazma yük devretme

OpenSearch Hizmeti içindeki bir yazma yük devretme işleminin orkestrasyonu, iyi tanımlanmış bir mekanizma aracılığıyla seçilen lider düğüm tarafından gerçekleştirilir. Bu mekanizma, küme durumunun yayınlanması için bir konsensüs protokolünü içerir ve tüm düğümler arasında, hizmetten çıkarma için (her zaman) tek bir bölgenin belirlenmesi konusunda oybirliğiyle anlaşma sağlanmasını sağlar. Daha da önemlisi, etkilenen bölgeyle ilgili meta veriler, bir kesinti durumunda tam yeniden başlatma sırasında bile kalıcılığını sağlamak için tüm düğümlerde kopyalanır.

Ayrıca lider düğüm, G/Ç çitlemeyi başlatmadan önce başlangıçta etkilenen bölgelerdeki düğümleri 5 dakika süreyle beklemeye alarak yumuşak ve zarif bir geçiş sağlar. Bu bilinçli yaklaşım, yeni koordinatör trafiğinin veya parça sorgusu trafiğinin etkilenen bölgedeki düğümlere yönlendirilmesini engeller. Bu da, bu düğümlerin devam eden görevlerini zarif bir şekilde tamamlamasına ve hizmet dışı bırakılmadan önce tüm uçuş içi istekleri kademeli olarak yerine getirmesine olanak tanır. Aşağıdaki diyagram bu mimariyi göstermektedir.

Lider düğüm için yazma yük devretmesi uygulama sürecinde OpenSearch Hizmeti şu temel adımları izler:

• Liderin tahttan çekilmesi – Lider düğüm, yazma yük devretmesi için planlanmış bir bölgede bulunuyorsa sistem, lider düğümün liderlik rolünden gönüllü olarak çekilmesini sağlar. Bu feragat kontrollü bir şekilde gerçekleştirilir ve tüm süreç, gerekli eylemlerin sorumluluğunu üstlenecek uygun başka bir düğüme devredilir.
• Görevden alınacak liderin yeniden seçilmesini önleyin – Yazma yük devretme için işaretlenmiş bir bölgeden liderin yeniden seçilmesini önlemek için uygun lider düğüm, yazma yük devretme eylemini başlattığında, hizmet dışı bırakılacak lider düğümlerin bir sonraki seçime katılmamasını sağlayacak önlemler alır. Bu, hizmet dışı bırakılacak lider düğümün oylama yapılandırmasının dışında tutulması ve kümenin operasyonunun herhangi bir kritik aşamasında oy kullanmasının etkili bir şekilde engellenmesiyle gerçekleştirilir.

Yazma yük devretme bölgesine ilişkin meta veriler küme durumu içinde depolanır ve bu bilgiler dağıtılmış OpenSearch Hizmeti kümesindeki tüm düğümlere aşağıdaki şekilde yayınlanır:

"decommissionedAttribute": {
    "awareness": {
        "zone": "us-east-1c"
     },
     "status": "successful",
     "requestID": "FLoyf5v9RVSsaAquRNKxIw"
}

Aşağıdaki ekran görüntüsü, bir bölgedeki ağ iletişimi yavaşlaması sırasında yazma yük devretmenin kullanılabilirliğin kurtarılmasına yardımcı olduğunu göstermektedir.

Yazma yük devretmesi sonrasında bölgesel kurtarma

Bölgesel yeniden devreye alma süreci, bölgesel yazma yük devretme işleminin ardından kurtarma aşamasında çok önemli bir rol oynar. Etkilenen bölge geri yüklendikten ve kararlı kabul edildikten sonra, daha önce hizmet dışı bırakılan düğümler kümeye yeniden katılacaktır. Bu yeniden hizmete alma genellikle bölgenin yeniden hizmete alınmasından sonraki 2 dakikalık bir zaman dilimi içinde gerçekleşir.

Bu onların eş düğümleriyle senkronize olmalarını sağlar ve kopya parçaları için kurtarma sürecini başlatarak kümeyi etkili bir şekilde istenen duruma geri yükler.

Sonuç

Bekleme özellikli OpenSearch Service Multi-AZ'nin piyasaya sürülmesi, işletmelere kritik iş yükleri için yüksek kullanılabilirlik ve tutarlı performans elde etmek için güçlü bir çözüm sağlar. Bu dağıtım seçeneğiyle işletmeler altyapılarının dayanıklılığını artırabilir, küme yapılandırmasını ve yönetimini basitleştirebilir ve en iyi uygulamaları uygulayabilir. Ağırlıklı çevrimsel parça kopya seçimi, proaktif yük devretme mekanizmaları ve arıza durumunda açık yedek Erişilebilirlik Alanları gibi özelliklerle, Bekleme Özellikli OpenSearch Service Multi-AZ, zorlu kurumsal ortamlar için güvenilir ve verimli bir arama deneyimi sağlar.

Bekleme Özellikli Multi-AZ hakkında daha fazla bilgi için bkz. Başlık Altında Amazon OpenSearch Hizmeti: Bekleme Özellikli Multi-AZ.

Yazar Hakkında

Anshu Agarwal Amazon Web Services'ta AWS OpenSearch üzerinde çalışan Kıdemli Yazılım Mühendisidir. Ölçeklenebilir ve son derece güvenilir sistemler oluşturmaya ilişkin sorunları çözme konusunda tutkulu.

Rişab Nahata Amazon Web Services'ta OpenSearch üzerinde çalışan bir Yazılım Mühendisidir. Dağıtılmış sistemlerde problem çözme konusunda büyülenmiştir. OpenSearch'e aktif olarak katkıda bulunmaktadır.

Buktaver Han Amazon OpenSearch Hizmeti üzerinde çalışan bir Baş Mühendistir. Dağıtık ve otonom sistemlerle ilgileniyor. OpenSearch'e aktif olarak katkıda bulunmaktadır.

Ranjith Ramachandra Amazon Web Services'de Amazon OpenSearch Service üzerinde çalışan bir Mühendislik Yöneticisidir.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/big-data/achieve-high-availability-in-amazon-opensearch-multi-az-with-standby-enabled-domains-a-deep-dive-into-failovers/