CAP teoremi dağıtık sistem teorisinin temel taşıdır. Tabii ki, onu çevreleyen tartışmalar azalmaz: İçindeki tanımlar kanonik değildir ve kesin bir kanıt yoktur... Bununla birlikte, günlük sağduyunun™ pozisyonlarına sıkı sıkıya bağlı kalarak, teoremin doğru olduğunu sezgisel olarak anlıyoruz.
Açık olmayan tek şey "P" harfinin anlamıdır. Küme bölündüğünde, yeterli sayıya ulaşılıncaya kadar yanıt vermemeye veya mevcut verileri geri verip vermemeye karar verir. Bu seçimin sonuçlarına bağlı olarak sistem CP veya AP olarak sınıflandırılır. Örneğin Cassandra, küme ayarlarına bağlı olarak değil, her bir özel isteğin parametrelerine bağlı olarak her iki şekilde de davranabilir. Ancak sistem "P" değilse ve bölünürse ne olacak?
Bu sorunun cevabı biraz beklenmedik: CA kümesi bölünemez.
Bu nasıl bir kümedir ki bölünemez?
Böyle bir kümenin vazgeçilmez bir özelliği, paylaşılan bir veri depolama sistemidir. Çoğu durumda bu, CA çözümlerinin kullanımını SAN altyapısını koruyabilen büyük kuruluşlarla sınırlayan bir SAN üzerinden bağlanmak anlamına gelir. Birden fazla sunucunun aynı verilerle çalışabilmesi için kümelenmiş bir dosya sistemine ihtiyaç vardır. Bu tür dosya sistemleri HPE (CFS), Veritas (VxCFS) ve IBM (GPFS) portföylerinde mevcuttur.
Oracle RAC'ı
Gerçek Uygulama Kümesi seçeneği ilk olarak 2001 yılında Oracle 9i'nin piyasaya sürülmesiyle ortaya çıktı. Böyle bir kümede birden fazla sunucu örneği aynı veritabanıyla çalışır.
Oracle, hem kümelenmiş bir dosya sistemiyle hem de kendi çözümü olan ASM, Otomatik Depolama Yönetimi ile çalışabilir.
Her nüsha kendi günlüğünü tutar. İşlem bir örnek tarafından yürütülür ve taahhüt edilir. Bir bulut sunucusu başarısız olursa, hayatta kalan küme düğümlerinden (örneklerden) biri onun günlüğünü okur ve kayıp verileri geri yükler, böylece kullanılabilirlik sağlanır.
Tüm örnekler kendi önbelleklerini korur ve aynı sayfalar (bloklar) aynı anda birden fazla örneğin önbelleklerinde bulunabilir. Üstelik bir örneğin bir sayfaya ihtiyacı varsa ve başka bir örneğin önbelleğinde bulunuyorsa, bunu diskten okumak yerine önbellek birleştirme mekanizmasını kullanarak komşusundan alabilir.
Peki örneklerden birinin verileri değiştirmesi gerekirse ne olur?
Oracle'ın özelliği, özel bir kilitleme hizmetine sahip olmamasıdır: Sunucu bir satırı kilitlemek isterse, kilit kaydı doğrudan kilitli satırın bulunduğu bellek sayfasına yerleştirilir. Bu yaklaşım sayesinde Oracle, monolitik veritabanları arasında performans şampiyonudur: kilitleme hizmeti hiçbir zaman darboğaz haline gelmez. Ancak küme konfigürasyonunda böyle bir mimari, yoğun ağ trafiğine ve kilitlenmelere yol açabilir.
Bir kayıt kilitlendiğinde, bir örnek diğer tüm örneklere bu kaydı saklayan sayfanın özel bir muhafazaya sahip olduğunu bildirir. Başka bir örneğin aynı sayfadaki bir kaydı değiştirmesi gerekiyorsa, sayfadaki değişiklikler taahhüt edilene kadar, yani değişiklik bilgisi diskteki bir günlüğe yazılana kadar beklemelidir (ve işlem devam edebilir). Ayrıca bir sayfanın birkaç kopya halinde sırayla değişmesi de mümkündür ve ardından sayfayı diske yazarken bu sayfanın güncel sürümünü kimin sakladığını bulmanız gerekebilir.
Aynı sayfaların farklı RAC düğümlerinde rastgele güncellenmesi, veritabanı performansının önemli ölçüde düşmesine ve küme performansının tek bir örneğinkinden daha düşük olabileceği noktaya neden olur.
Oracle RAC'ın doğru kullanımı, verileri fiziksel olarak bölümlemek (örneğin, bölümlenmiş bir tablo mekanizması kullanarak) ve her bölüm kümesine özel bir düğüm aracılığıyla erişmektir. RAC'ın temel amacı yatay ölçeklendirme değil, hata toleransını sağlamaktı.
Bir düğüm kalp atışına yanıt vermeyi durdurursa, bunu ilk algılayan düğüm diskte bir oylama prosedürünü başlatır. Eksik düğüm burada belirtilmezse, düğümlerden biri veri kurtarma sorumluluğunu üstlenir:
- eksik düğümün önbelleğindeki tüm sayfaları "dondurur";
- eksik düğümün günlüklerini okur (yeniden yapar) ve bu günlüklerde kaydedilen değişiklikleri yeniden uygular, aynı anda diğer düğümlerin değiştirilen sayfaların daha yeni sürümlerine sahip olup olmadığını kontrol eder;
- Bekleyen işlemleri geri alır.
Düğümler arasında geçişi kolaylaştırmak için Oracle'ın bir hizmet kavramı vardır - sanal bir örnek. Bir örnek birden fazla hizmete hizmet verebilir ve bir hizmet, düğümler arasında hareket edebilir. Veritabanının belirli bir bölümüne (örneğin, bir istemci grubu) hizmet veren bir uygulama örneği, bir hizmetle çalışır ve veritabanının bu bölümünden sorumlu olan hizmet, bir düğüm arızalandığında başka bir düğüme taşınır.
İşlemler için IBM Pure Data Systems
2009 yılında Blue Giant portföyünde DBMS için bir küme çözümü ortaya çıktı. İdeolojik olarak “normal” ekipman üzerine inşa edilen Paralel Sysplex kümesinin halefidir. 2009'da bir yazılım paketi olan DB2 pureScale piyasaya sürüldü ve 2012'de IBM, İşlemler için Saf Veri Sistemleri adlı bir aracı sundu. Netezza'nın yeniden adlandırılmasından başka bir şey olmayan Pure Data Systems for Analytics ile karıştırılmamalıdır.
İlk bakışta, pureScale mimarisi Oracle RAC'a benzer: aynı şekilde, birkaç düğüm ortak bir veri depolama sistemine bağlanır ve her düğüm, kendi bellek alanları ve işlem günlükleriyle kendi DBMS örneğini çalıştırır. Ancak Oracle'dan farklı olarak DB2, bir dizi db2LLM* işlemiyle temsil edilen özel bir kilitleme hizmetine sahiptir. Küme konfigürasyonunda bu hizmet, Paralel Sysplex'te birleştirme tesisi (CF) ve Pure Data'da PowerHA olarak adlandırılan ayrı bir düğüme yerleştirilir.
PowerHA aşağıdaki hizmetleri sağlar:
- kilit yöneticisi;
- genel arabellek önbelleği;
- süreçler arası iletişim alanı.
Verileri PowerHA'dan veritabanı düğümlerine ve geriye aktarmak için uzaktan bellek erişimi kullanılır, dolayısıyla küme ara bağlantısının RDMA protokolünü desteklemesi gerekir. PureScale, Ethernet üzerinden hem Infiniband'ı hem de RDMA'yı kullanabilir.
Bir düğümün bir sayfaya ihtiyacı varsa ve bu sayfa önbellekte değilse, düğüm genel önbellekteki sayfayı ister ve yalnızca orada yoksa onu diskten okur. Oracle'ın aksine, istek komşu düğümlere değil yalnızca PowerHA'ya gider.
Bir örnek bir satırı değiştirecekse onu özel modda, satırın bulunduğu sayfayı ise paylaşılan modda kilitler. Tüm kilitler genel kilit yöneticisine kayıtlıdır. İşlem tamamlandığında düğüm, değiştirilen sayfayı genel önbelleğe kopyalayan, kilitleri serbest bırakan ve değiştirilen sayfayı diğer düğümlerin önbelleklerinde geçersiz kılan kilit yöneticisine bir mesaj gönderir.
Değiştirilen satırın bulunduğu sayfa zaten kilitliyse, kilit yöneticisi, değişikliği yapan düğümün belleğinden değiştirilen sayfayı okuyacak, kilidi serbest bırakacak, değiştirilen sayfayı diğer düğümlerin önbelleklerinde geçersiz kılacak ve sayfa kilidini isteyen düğüme verin.
"Kirli", yani değiştirilmiş sayfalar hem normal bir düğümden hem de PowerHA'dan (castout) diske yazılabilir.
PureScale düğümlerinden biri başarısız olursa, kurtarma yalnızca başarısızlık anında henüz tamamlanmayan işlemlerle sınırlıdır: Tamamlanan işlemlerde o düğüm tarafından değiştirilen sayfalar PowerHA'daki genel önbellekte bulunur. Düğüm, kümedeki sunuculardan birinde azaltılmış bir yapılandırmayla yeniden başlatılır, bekleyen işlemleri geri alır ve kilitleri serbest bırakır.
PowerHA iki sunucuda çalışır ve ana düğüm, durumunu eşzamanlı olarak çoğaltır. Birincil PowerHA düğümü arızalanırsa küme, yedek düğümle çalışmaya devam eder.
Elbette veri setine tek bir düğüm üzerinden erişirseniz kümenin genel performansı daha yüksek olacaktır. PureScale, belirli bir veri alanının bir düğüm tarafından işlendiğini bile fark edebiliyor ve ardından o alanla ilgili tüm kilitler, PowerHA ile iletişim kurmadan düğüm tarafından yerel olarak işlenecek. Ancak uygulama bu verilere başka bir düğüm aracılığıyla erişmeye çalıştığında merkezi kilit işleme devam edecek.
IBM'in gerçek dünyadaki üretim iş yüklerine çok benzeyen %90 okuma ve %10 yazma iş yüküne ilişkin dahili testleri, 128 düğüme kadar neredeyse doğrusal ölçeklendirme olduğunu gösteriyor. Test koşulları ne yazık ki açıklanmadı.
HPE Kesintisiz SQL
Hewlett-Packard Enterprise portföyünün ayrıca yüksek düzeyde kullanılabilirliğe sahip kendi platformu vardır. Bu, 1976 yılında Tandem Computers tarafından piyasaya sürülen NonStop platformudur. 1997 yılında şirket Compaq tarafından satın alındı ve 2002 yılında Hewlett-Packard ile birleşti.
NonStop, HLR veya banka kartı işlemleri gibi kritik uygulamalar oluşturmak için kullanılır. Platform, bilgi işlem düğümlerini, veri depolama sistemini ve iletişim ekipmanını içeren bir yazılım ve donanım kompleksi (cihaz) biçiminde teslim edilir. ServerNet ağı (modern sistemlerde - Infiniband) hem düğümler arasında alışverişe hem de veri depolama sistemine erişime hizmet eder.
Sistemin ilk versiyonları birbiriyle senkronize edilmiş özel işlemciler kullanıyordu: tüm işlemler birkaç işlemci tarafından eşzamanlı olarak gerçekleştirildi ve işlemcilerden biri hata yaptığı anda kapatıldı ve ikincisi çalışmaya devam etti. Daha sonra sistem geleneksel işlemcilere (önce MIPS, ardından Itanium ve son olarak x86) geçti ve senkronizasyon için diğer mekanizmalar kullanılmaya başlandı:
- mesajlar: her sistem sürecinin bir "gölge" ikizi vardır ve aktif süreç buna periyodik olarak durumu hakkında mesajlar gönderir; ana işlemin başarısız olması durumunda, son mesajın belirlediği andan itibaren gölge süreç çalışmaya başlar;
- oylama: depolama sistemi, birden fazla özdeş erişimi kabul eden ve bunları yalnızca erişimler eşleştiğinde yürüten özel bir donanım bileşenine sahiptir; İşlemciler fiziksel senkronizasyon yerine eşzamansız çalışır ve çalışmalarının sonuçları yalnızca G/Ç anlarında karşılaştırılır.
1987'den bu yana, NonStop platformunda ilişkisel bir DBMS çalışıyor - önce SQL/MP ve daha sonra SQL/MX.
Veritabanının tamamı bölümlere ayrılmıştır ve her bölüm kendi Veri Erişim Yöneticisi (DAM) sürecinden sorumludur. Veri kaydetme, önbelleğe alma ve kilitleme mekanizmaları sağlar. Veri işleme, ilgili veri yöneticileriyle aynı düğümlerde çalışan Yürütücü Sunucu İşlemleri tarafından gerçekleştirilir. SQL/MX zamanlayıcı, görevleri uygulayıcılar arasında bölüştürür ve sonuçları toplar. Mutabık kalınan değişikliklerin yapılması gerektiğinde TMF (Transaction Management Facility) kütüphanesi tarafından sağlanan iki aşamalı taahhüt protokolü kullanılır.
NonStop SQL, uzun analitik sorguların işlemin yürütülmesini engellememesi için işlemleri önceliklendirebilir. Ancak amacı analitik değil, tam olarak kısa işlemlerin işlenmesidir. Geliştirici, NonStop kümesinin kullanılabilirliğini beş "dokuz" seviyesinde garanti eder, yani kesinti süresi yılda yalnızca 5 dakikadır.
SAP-HANA
HANA DBMS'nin (1.0) ilk kararlı sürümü Kasım 2010'da gerçekleşti ve SAP ERP paketi Mayıs 2013'te HANA'ya geçti. Platform, satın alınan teknolojilere dayanmaktadır: TREX Arama Motoru (sütunlu depolamada arama), P*TIME DBMS ve MAX DB.
“HANA” kelimesinin kendisi bir kısaltmadır: Yüksek Performanslı Analitik Cihaz. Bu DBMS, herhangi bir x86 sunucusunda çalışabilen kod biçiminde sağlanır, ancak endüstriyel kurulumlara yalnızca sertifikalı ekipmanlarda izin verilir. HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC'den temin edilebilen çözümler. Bazı Lenovo yapılandırmaları SAN olmadan çalışmaya bile izin verir; ortak depolama sisteminin rolü, yerel disklerdeki GPFS kümesi tarafından oynanır.
Yukarıda listelenen platformlardan farklı olarak HANA, bellek içi bir DBMS'dir; yani birincil veri görüntüsü RAM'de saklanır ve bir olağanüstü durum durumunda kurtarma için yalnızca günlükler ve periyodik anlık görüntüler diske yazılır.
Her HANA küme düğümü, verilerin kendi kısmından sorumludur ve veri haritası, koordinatör düğümde bulunan özel bir bileşen olan Ad Sunucusu'nda saklanır. Veriler düğümler arasında kopyalanmaz. Kilitleme bilgileri de her düğümde depolanır, ancak sistemin küresel bir kilitlenme algılayıcısı vardır.
Bir HANA istemcisi bir kümeye bağlandığında topolojisini indirir ve ihtiyaç duyduğu verilere bağlı olarak herhangi bir düğüme doğrudan erişebilir. Bir işlem tek bir düğümün verilerini etkiliyorsa, o düğüm tarafından yerel olarak yürütülebilir, ancak birkaç düğümün verileri değişirse, başlatan düğüm, dağıtılmış işlemi açan ve koordine eden koordinatör düğümle iletişim kurar ve bunu bir kod kullanarak gerçekleştirir. optimize edilmiş iki aşamalı taahhüt protokolü.
Koordinatör düğümü kopyalanır, böylece koordinatör başarısız olursa yedek düğüm hemen görevi devralır. Ancak veri içeren bir düğüm başarısız olursa, verilerine erişmenin tek yolu düğümü yeniden başlatmaktır. Kural olarak HANA kümeleri, üzerinde kaybedilen bir düğümü mümkün olan en kısa sürede yeniden başlatmak için yedek bir sunucu bulundurur.
Kaynak: habr.com