Merhaba;
Bugün Dell EMC PowerStore çözümünden bahsetmek istiyorum. Özellikle MongoDB gibi esnek ve ölçeklenebilir yapılarıyla dikkat çeken yeni analitik uygulamaların, bu uygulamalara uygun şekilde tasarlanan donanımlarla birleştirildiğine iş taleplerine daha duyarlı, çevik ve verimli yapıların oluşmasını sağlayabileciğimiz çok açıktır. Biliyorsunuz son yıllarda özellikle, “uygulama farkında” geliştirilen donanımlarla, uygulamanın gerçek gücünü ortaya çıkarabiliyoruz. Oracle Database için Exadata sistemleri, NetBackup için Veritas NetBackup Appliance sistemi veya hyper-converged yapılar aslında kullanılacak iş yüklerine göre donanımın daha optimize edilmesi ilkesine dayanır. Aynı şey modern pek çok yeni uygulamalar için de geçerlidir. Uygulamanın mimarisini, çalışma şeklini anlayıp, bu ihtiyaca özel olarak tasarlanan yapılar, donanımlar sayesinde uygulamadan maksimum fayda sağlamış oluruz. Yani daha verimli, daha performanslı, istendiğinde daha hızlı ölçeklendirilebilen yapılarla iş taleplerimizi istediğimiz çeviklikte karşılayabiliriz. İşte bugünkü hikayemiz, MongoDB ve PowerStore’un birlikteliği olacak.
PowerStore, konteyner tabanlı mikroservis mimarisini ve gelişmiş depolama birimi teknolojilerini kullanmaktadır. Entegre makine öğrenmesi sayesinde, verinizin içinde saklı olan gücü iş taleplerinize uygun şekilde ortaya çıkarabilmektedir. Performans merkezli tasarıma sahip olan PowerStore, çok yönlü bir platformdur. “Always-on” veri azaltma teknolojisini de içinde barındırır. Tahmine dayalı analitik özellikleri sayesinde ortamı izler, analiz eder ve sorunları giderir. PowerStore T ve PowerStore X modelleri mevcuttur. PowerStore T modeli, “bare-metal” çözüm sunarken; PowerStore X, “AppsON” yeteneği sayesinde, uygulamaları, “appliance” üzerinde çalıştırır. Yerel (“native”) ESXi katmanı vardır. Uygulamalar, sanal makineler üzerinde çalışır.
MongoDB, yapılandırılmış ve yapılandırılmamış verileri depolamak için belge (döküman) tabanlı bir veri modeli kullanan modern bir NoSQL veritabanıdır. MongoDB, ölçeklenebilir ve çok büyük miktarda veriyi verimli bir şekilde işleyebilir. Örneğin, bir MongoDB Veritabanı, “petabayt”larca verinin dağıtıldığı yüzlerce sistem üzerinde ölçeklendirebilir. Yukarda alsında belirttiğim gibi, modern bir veritabanı mimarisi, modern depolama ve uygulama odaklı altyapı ihtiyacını da beraberinde getirir.
MongoDB, veri kullanılabilirliğini ve hata toleransını artırmak için replika setlerle tasarlanmış bir mimariye sahiptir. Verilerin tam kopyaları, birden çok ikincil üyeye (“secondary members”) kopyalanır. Tek bir replika seti 50 üyeye kadar destekler. Elbette, fazla sayıda kopya kullanmak, veri kullanılabilirliğini ve veri korumasını artırır. Açıktır ki replika setler sayesinde planlı veya plansız kesintilerde ( sunucu güncellemeleri, sunucu hataları, rack birim hataları, veri merkezi, network hataları gibi), birincil üyenin yükü otomatik devretmesi sağlanır. Verinin, farklı bir veri merkezinde farklı bir sunucuya replikasyonu veri kullanılabilirliğini ve dağıtık istemciler için veriye erişim kalitesini artırır. Fakat, çok fazla replika sete sahip olmak, depolama birimi kullanım verimliliğini düşürür, yüksek ağ (“network”) bant genişliğine ihtiyaç duyar ve yönetim karmaşıklığını artırır.
İşte bu zorlukların üstesinden gelebilmek için Dell, PowerStore çözümünü önermektedir. Entegre veri azaltma özelliği, AppsON ile uygulamaların depolama birimine yakınlaştırılması ve Vmware sanallaştırma ortamının depolama birimi platformuyla sıkı entegrasyonu sayesinde bu zorlukların hafifletilebileceği özellikle vurgulanmaktadır.
Üç üyeden oluşan mongoDB replika set mimarisine bir göz atalım.
PowerStore’un MongoDB için sağlayacağı faydaları görebilmemiz için MongoDB mimarisini anlamamız önemli olacaktır.
Varsayılan olarak, replika set için, birincil üye okuma ve yazma operasyonlarından sorumludur. İstemciler, okuma işlemlerini en yakın ikincil üyelere göndermek için okuma tercihi de belirtebilir. Yedek kopya için isterseniz, “data-bearing” olarak isimlendirdiğimiz üye konfigürasyonu da yapabilirsiniz. Bu üye gerektiğinde yedek kopya olarak hizmet verebilir.
Elbette iş yükü artıkça, birincil ve ikincil üyeler, işleme güçlerini, CPU, bellek veya IO olarak ölçeklendirebilmelidir. Özellikle okuma ağırlıklı iş yükleri için her birinde tam veri kopyası olacak şekilde çok fazla ikincil üyelere ihtiyaç olabilir. Veri dayanıklılığını artırmak ve birincil üye başarısız olduğunda, verilerin geri alınması ihtiyacını ortadan kaldırmak için, “write concern” tanımlayabilirsiniz. Bu tanımı, çoğunluk değeri (“majority”) ve oy hakkına sahip tüm üyelerde günlüğe (“journal”) kaydetmeyi etkinleştirerek yapabilirsiniz. “Write concern”, yazma işlemlerini başarılı olduğunu kabul etmeden önce yazma işlemlerini kaç üyenin kabul etmesi gerektiğini belirtir. Replika set için varsayılan yazma sorunu (“write concern”) 1’dir. Yani üye yazma işlemini uyguladıktan sonra birincil üyenin bir başarı onayı döndürmesi yeterlidir. (“Write concern”), çoğunluk (“majority”) olarak tanımlandığında, MongoDB, üyelerden alınması gereken bilgilendirme sayısını hesaplar. “WiredTiger” günlüğü (“journal”), “write-ahead” işlem “log”udur. Yani, değişiklikler uygulanmadan önce “log”a yazılır. Günlük “log”lar, (“journal logs”), kontrol noktaları (“checkpoints”) arasındaki tüm veri değişikliklerini korur. Yani, MongoDB, kontrol noktaları arasında başarısız olduğunda, son kontrol noktasından bu yana yapılan değişiklikleri tekrar oynatmak için günlük “log”ları kullanır.
Büyük veri kümeleri içeren ve yüksek verimlilik gerektiren ortamlar için, MongoDB “sharding” işlemini kullanır. Yani, depolama kapasitesini, performansı, iş hacmini artırmak için veriyi birden fazla sisteme dağıtır.
“sharded” kümesi (“cluster”), üç önemli bileşenden oluşur:
“Shards”: Verinin bir alt kümesini tutar ve replika set olarak konuşlandırılır.
“Mongos”: Konfigürasyon sunucular arasında iletişimi sağlar ve istemci isteklerini uygun “shard”lara yönlendirir.
“Config servers”: Küme (“cluster”) konfigürasyonu değerleri için “metadata”yı tutar.
“sharded cluster”da, her “shard”, ilgili veri setine yazma operasyonunu yapabilir.
Veritabanı söz konusu olunca, depolama platform motorlarından bahsetmeden geçmek olmaz elbette. MongoDB, operasyonel ve gerçek-zamanlı analitik iş yüklerini destekler. Aslında, geleneksel ve kritik pek çok iş yükünü destekler. MongoDB, takılabilir/genişletilebilir depolama mimarisi sayesinde, bu farklı iş yüklerini destekler. Bahsedilen bu depolama motorları, verinin ne şekilde depolanacağından sorumludur. MongoDB 4.2 sürümüyle birlikte, farklı türede depolama motorları desteklenmektedir: “WiredTiger storage engine”, “in-memory engine”, “encrypted storage engine”.
PowerStore AppsON yeteneği, MongoDB için kritik öneme sahip. AppsON, VMware vSphere ile entegre çalışmaktadır. Yani, depolama kaynakları, sanallaştırma katmanı ile doğrudan bağlantılıdır. Bu sayede MongoDB, sunucu ve depolama sanallaştırmasından maksimum fayda sağlar.
PowerStore, MongoDB’nin “scale-up” ve “scale-out” dağıtım modellerine cevap verebilir. Entegre hipervizör katmanı, iş yükü ihtiyaç duyduğunda replika setlerini dinamik olarak ölçeklendirebilir. Replika setleri veya “shard”lar, aynı “appliance” üzerinde veya farklı lokasyonlardaki “aapliance”lar üzerinde provizyonlanabilir.
PowerStore’da, NDU özelliği (“non-distruptive upgrade”), PowerStore’un kullanabilirliğini daha da artırır. NDU, yazılım güncellemelerini, “hotfix”, donanım ve disk mikro kod güncellemelerini destekler. Powerstore’un içine gömülü VMware vSphere High Availability (HA) sayesinde, hata veren MongoDB sunucular, diğer ESXi node üzerinde başlatılabilir.
Daha da yüksek düzeyde bir yedeklilik ve uygulama kullanılabilirliği elde etmek için MongoDB’yi farklı veri merkezlerindeki birden çok PowerStore cihazında (coğrafi yedeklilik), replika set ve “sharded cluster” yapılar şeklinde dağıtabilirsiniz.
MongoDB’nin replika setlerini, PowerStore üzerinde tuttuğunuzda, “always-on inline data reduction” özelliği sayesinde, gerçek depolama ihtiyacını büyük ölçüde azaltır. Depolama ihtiyacı azalırken, MongoDB kendisinden beklenen verilerinin kullanılabilirliğini ve korumasını sürdürür.
Veritabanının etkin bir şekilde yedeklenmesinin ne derece önemli olduğunu biliyoruz. Snapshot’lar sayesinde, verinin anlık kopyasını alabilirsiniz. Anlık kopyalar, verilerin tam kopyasını içerir ve bu kopyaları, uygulama testleri, yedekleme kopyaları veya DevOps süreçleriniz için kullanabilirsiniz. PowerStore’un, Vmware vSphere ile olan sıkı entegrasyonu sayesinde, “PowerStore Manager” üzerinden istendiği an veya uygun zamana planlama yaparak “vVols VM snapshots”ları alabilirsiniz. “VM snapshot”ları, PowerStore veya vCenter üzerinden görüntüleyebilirsiniz.
Yüksek değerli veri ile çalışan firmalar için, veri güvenliğinin sağlanması en kritik ve önemli konulardan biridir. Kayıp veya çalınan bir veri hem prestij kaybına neden olduğu gibi hem de büyük finansal kayıpları de beraberinde getirmektedir. PowerStore D@RE (256-bit Advanced Encryption Standard (AES) ), MongoDB’ye ek bir yük getirmeden, veri güvenliğini sağlamaktadır.
Veri merkezine yeni gelen bir cihazın veya uygulamanın etkin bir şekilde izlenmesinin önemini hepimiz biliyoruz. Mevcut vCenter ortamına PowerStore’u dahil ederek, tek bir merkezden tüm VMware altyapınızı yönetebilirsiniz.
Özet olarak şunu belirtebiliriz, MongoDB gibi yeni iş analitiği uygulamaları, verinin kullanılma şeklini önemli derecede değiştiriyor. Büyük miktarda veri ve yeni teknolojiler, organizasyonlara değişim için büyük imkanlar sunmaktadır. Verilerin değeri ve ölçeği büyüdükçe, gelecekteki büyüme için teknik yenilikler sağlayan, uygulama mimarisi için ihtiyaç duyulan özellikleri içinde barındıran, kolay yönetilebilir geleceğe dönük bir platformun hayata geçirilmesinin önemli olduğunu düşünüyorum. Anlatılan özellikler ile PowerStore üzerinde konumlandırılan MongoDB, organizasyonlara ihtiyaç duydukları çevikliği, verimliliği sağlayacak ve iş taleplerine anlık cevap vermelerini kolaylaştıracak gibi görünüyor.
Sarav Asiye Yiğit – 17 Ekim 2020 Cumartesi
Kaynakça:
https://docs.mongodb.com/manual/reference/write-concern/
Leave A Comment