Her nasılsa, tarihsel olarak, BT endüstrisi herhangi bir nedenle iki koşullu kampa bölünmüştür: "yanında" olanlar ve "karşısında" olanlar. Üstelik uyuşmazlıkların konusu tamamen keyfi de olabiliyor. Hangi işletim sistemi daha iyi: Win mi Linux mu? Android veya iOS akıllı telefonda mı? Her şeyi bulutlarda mı saklamanız gerekiyor, yoksa soğuk RAID deposuna mı koyup vidaları bir kasaya mı koymanız gerekiyor? PHP çalışanlarının programcı olarak adlandırılma hakkı var mı? Bu anlaşmazlıklar bazen doğası gereği tamamen varoluşsaldır ve spor çıkarları dışında hiçbir temeli yoktur.
Öyle oldu ki, konteynerlerin ve liman işçisi ve koşullu k8'lerin bulunduğu tüm bu sevilen mutfağın ortaya çıkışıyla, arka ucun çeşitli alanlarında yeni yeteneklerin kullanımına "lehinde" ve "karşı" tartışmalar başladı. (Bu tartışmada çoğunlukla Kubernetes'in orkestratör olarak belirtilmesine rağmen, bu özel aracın seçiminin temel bir önemi olmadığını önceden belirtelim. Bunun yerine, size en uygun ve tanıdık gelen başka bir araçla değiştirebilirsiniz. .)
Ve öyle görünüyor ki bu, aynı madalyonun iki yüzü arasındaki basit bir anlaşmazlık olacaktır. Yeterli sayıda insanın ortada bir yerde var olduğu Win ile Linux arasındaki ebedi çatışma kadar anlamsız ve acımasız. Ancak konteynerleştirme durumunda her şey o kadar basit değil. Genellikle bu tür anlaşmazlıklarda doğru taraf yoktur, ancak veritabanlarını depolamak için kapların "kullanılması" veya "kullanılmaması" durumunda her şey tersine döner. Çünkü bir bakıma bu yaklaşımın hem destekçileri hem de karşıtları haklıdır.
İyi taraf
Aydınlık Taraf'ın argümanı kısaca tek bir cümleyle özetlenebilir: "Merhaba, 2k19 pencerenin dışında!" Kulağa popülizm gibi geliyor elbette ama konuyu detaylı incelerseniz avantajları da var. Şimdi bunları sıralayalım.
Diyelim ki büyük bir web projeniz var. Başlangıçta mikro hizmet yaklaşımı temel alınarak oluşturulmuş olabilir veya bir noktada evrimsel bir yoldan gelmiş olabilir - bu aslında çok da önemli değil. Projemizi ayrı mikro hizmetlere dağıttınız, orkestrasyonu, yük dengelemeyi ve ölçeklendirmeyi ayarladınız. Ve şimdi, habra efektleri sırasında düşmüş sunucuları kaldırmak yerine, rahat bir vicdanla hamakta mojito yudumluyorsunuz. Ancak tüm eylemlerde tutarlı olmalısınız. Çoğu zaman yalnızca uygulamanın kendisi (kod) kapsayıcıya alınır. Kod dışında başka nelerimiz var?
Bu doğru, veriler. Herhangi bir projenin kalbi, verileridir: bu, tipik bir DBMS (MySQL, Postgre, MongoDB) veya arama için kullanılan depolama (ElasticSearch), önbelleğe alma için anahtar/değer depolama (örneğin, redis vb.) olabilir. kötü yazılmış sorgular nedeniyle veritabanı çöktüğünde çarpık arka uç uygulama seçeneklerinden bahsedeceğiz ve bunun yerine bu veritabanının istemci yükü altında hata toleransının sağlanmasından bahsedeceğiz. Sonuçta, uygulamamızı kapsayıcıya aldığımızda ve herhangi bir sayıda gelen isteği işleyecek şekilde serbestçe ölçeklenmesine izin verdiğimizde, bu doğal olarak veritabanındaki yükü artırır.
Aslında, veritabanına erişim kanalı ve üzerinde çalıştığı sunucu, güzel konteynerleştirilmiş arka uçumuzda iğnenin gözü haline gelir. Aynı zamanda, konteyner sanallaştırmanın ana nedeni, yapının mobilitesi ve esnekliğidir; bu, pik yüklerin, elimizdeki tüm altyapı boyunca dağıtımını mümkün olduğunca verimli bir şekilde organize etmemize olanak tanır. Yani, sistemin mevcut tüm unsurlarını küme genelinde kapsayıcı hale getirip yaymazsak, çok ciddi bir hata yapıyoruz.
Yalnızca uygulamanın kendisini değil, veri depolamaktan sorumlu servisleri de kümelemek çok daha mantıklıdır. Bağımsız çalışan ve yükü kendi aralarında k8'lerde dağıtan web sunucularını kümeleyerek ve dağıtarak, veri senkronizasyonu sorununu zaten çözüyoruz - bazı medya veya blog platformlarını örnek alırsak, gönderilerdeki aynı yorumlar. Her durumda, veritabanının bir Harici Hizmet olarak küme içi, hatta sanal bir temsiline sahibiz. Sorun şu ki, veritabanının kendisi henüz kümelenmemiş - küpte konuşlandırılan web sunucuları, değişiklikler hakkında bilgileri ayrı olarak dönen statik savaş veritabanımızdan alıyor.
Bir yakalama sezdin mi? Yükü dağıtmak ve ana web sunucusunun çökmesini önlemek için k8s veya Swarm kullanıyoruz, ancak bunu veritabanı için yapmıyoruz. Ancak veritabanı çökerse, kümelenmiş altyapımızın tamamı anlamsızlaşır; veritabanı erişim hatası veren boş web sayfalarının ne faydası var?
Bu nedenle genellikle yapıldığı gibi sadece web sunucularını değil aynı zamanda veritabanı altyapısını da kümelemek gerekir. Tamamen tek bir ekip halinde çalışan, ancak aynı zamanda birbirinden bağımsız bir yapıyı ancak bu şekilde sağlayabiliriz. Üstelik, arka ucumuzun yarısı yük altında "çökse" bile geri kalanı hayatta kalacak ve veritabanlarını küme içinde birbirleriyle senkronize etme sistemi ve yeni kümeleri sonsuz şekilde ölçeklendirme ve dağıtma yeteneği, gerekli kapasiteye hızlı bir şekilde ulaşmaya yardımcı olacaktır - keşke veri merkezinde raflar olsaydı.
Ayrıca kümeler halinde dağıtılan veritabanı modeli, bu veritabanını ihtiyaç duyulan yere götürmenize olanak tanır; Küresel bir hizmetten bahsediyorsak, San Francisco bölgesinde bir yerde bir web kümesi oluşturmak ve aynı zamanda Moskova bölgesindeki bir veritabanına erişirken ve geri dönerken paketler göndermek oldukça mantıksızdır.
Ayrıca veritabanının konteynerleştirilmesi, sistemin tüm öğelerini aynı soyutlama düzeyinde oluşturmanıza olanak tanır. Bu da, yöneticilerin aktif katılımı olmadan, bu sistemin geliştiriciler tarafından doğrudan koddan yönetilmesini mümkün kılar. Geliştiriciler yeni alt proje için ayrı bir DBMS'nin gerekli olduğunu düşündüler - kolay! bir yaml dosyası yazdınız, onu kümeye yüklediniz ve işiniz bitti.
Ve elbette dahili operasyon büyük ölçüde basitleştirilmiştir. Söyleyin bana, ekibin yeni bir üyesi iş için savaş veritabanına girdiğinde gözlerinizi kaç kez kapattınız? Aslında sahip olduğunuz ve şu anda dönen tek şey hangisi? Tabii ki, burada hepimiz yetişkiniz ve bir yerlerde yeni bir yedeğimiz var ve hatta daha da uzakta - büyükannemin salatalıklarının ve eski kayaklarının olduğu rafın arkasında - başka bir yedek, hatta belki soğuk hava deposunda, çünkü ofisiniz bir zamanlar zaten yanıyordu. Ancak yine de, savaş altyapısına ve elbette savaş veritabanına erişimi olan yeni bir ekip üyesinin tanıtılması, etraftaki herkes için bir kova geçerliliktir. Peki onu kim tanıyor, acemi biri, belki de eli çaprazdır? Korkutucu, kabul edeceksin.
Konteynerizasyon ve aslında projenizin veritabanının dağıtılmış fiziksel topolojisi, bu tür doğrulama anlarının önlenmesine yardımcı olur. Yeni başlayan birine güvenmiyor musun? TAMAM! Ona çalışması için kendi kümesini verelim ve veritabanının diğer kümelerle olan bağlantısını keselim - yalnızca manuel olarak göndererek ve iki anahtarın (biri ekip lideri için, diğeri yönetici için) eşzamanlı dönüşüyle senkronizasyon. Ve herkes mutlu.
Artık veritabanı kümelemenin rakiplerine dönüşmenin zamanı geldi.
Karanlık taraf
Veritabanını kapsayıcı hale getirmenin ve tek bir merkezi sunucuda çalıştırmaya devam etmenin neden gerekli olmadığını tartışırken, ortodoks retoriğe ve "dedeler veritabanlarını donanım üzerinde çalıştırdı, biz de öyle yapacağız!" gibi ifadelere boyun eğmeyeceğiz. Bunun yerine, konteynırlaştırmanın gerçekten somut faydalar sağlayacağı bir durum bulmaya çalışalım.
Katılıyorum, bir kapta gerçekten bir tabana ihtiyaç duyan projeler, en iyi freze makinesi operatörü tarafından bir elin parmaklarıyla sayılamaz. Çoğunlukla, k8'lerin veya Docker Swarm'ın kullanımı bile gereksizdir - çoğu zaman bu araçlara, teknolojilerin genel aldatmacası ve cinsiyetlerin kişiliğindeki "her şeye kadir" olanın her şeyi kendi yoluna itme konusundaki tutumları nedeniyle başvurulur. bulutlar ve konteynerler. Çünkü artık moda ve herkes bunu yapıyor.
Vakaların en az yarısında bir projede Kubernetis'i veya yalnızca Docker'ı kullanmak gereksizdir. Sorun şu ki, müşterinin altyapısını korumak için görevlendirilen ekiplerin veya dış kaynak şirketlerinin tamamı bunun farkında değil. Konteynerlerin dayatılması daha da kötü çünkü müşteriye belirli miktarda paraya mal oluyor.
Genel olarak, docker/cube mafyasının bu altyapı sorunlarını dış kaynak kullanan müşterileri aptalca ezdiği yönünde bir görüş var. Sonuçta kümelerle çalışabilmek için bunu yapabilen ve uygulanan çözümün mimarisini genel olarak anlayan mühendislere ihtiyacımız var. Durumumuzu daha önce Cumhuriyet yayınında anlatmıştık; orada müşterinin ekibini Kubernetis'in gerçeklerinde çalışacak şekilde eğitmiştik ve herkes memnun kalmıştı. Ve iyiydi. Genellikle k8'in "uygulayıcıları" müşterinin altyapısını rehin alır - çünkü artık orada her şeyin nasıl çalıştığını yalnızca onlar anlıyorlar; müşterinin tarafında hiçbir uzman yok.
Şimdi bu şekilde sadece web sunucusu kısmını değil aynı zamanda veri tabanı bakımını da dış kaynaklardan sağladığımızı hayal edin. BD'nin kalp olduğunu ve kalbin kaybının her canlı için ölümcül olduğunu söyledik. Kısacası, beklentiler pek iyi değil. Bu nedenle, Kubernetis'in abartılı bir şekilde abartılması yerine birçok proje, site/projelerindeki yük ile ilgili tüm sorunları çözecek olan AWS için normal tarifeyle uğraşmamalıdır. Ancak AWS artık moda değil ve gösteriş paradan daha değerli; ne yazık ki BT ortamında da.
TAMAM. Belki de projenin gerçekten kümelenmeye ihtiyacı vardır, ancak durum bilgisi olmayan uygulamalarla ilgili her şey açıksa, kümelenmiş bir veritabanı için uygun ağ bağlantısını nasıl organize edebiliriz?
Eğer k8s'e geçiş gibi kusursuz bir mühendislik çözümünden bahsediyorsak, asıl baş ağrımız kümelenmiş bir veritabanındaki verilerin çoğaltılmasıdır. Bazı DBMS'ler başlangıçta verilerin kendi örnekleri arasındaki dağıtımına oldukça sadıktır. Pek çok kişi bu kadar hoş karşılanmıyor. Ve çoğu zaman projemiz için bir DBMS seçerken ana argüman, minimum kaynak ve mühendislik maliyetleriyle kopyalama yeteneği değildir. Özellikle proje başlangıçta bir mikro hizmet olarak planlanmadıysa ve sadece bu yönde geliştiyse.
Ağ sürücülerinin hızından bahsetmeye gerek olmadığını düşünüyoruz - yavaşlar. Onlar. Bir şey olursa, işlemci gücü veya boş RAM gibi daha fazla şeyin olduğu bir yerde bir DBMS örneğini yeniden başlatmak için hâlâ gerçek bir fırsatımız yok. Sanallaştırılmış disk alt sisteminin performansına çok hızlı bir şekilde ulaşacağız. Buna göre, DBMS'nin yakınlarda bulunan kendi kişisel makine setine çivilenmesi gerekir. Veya sözde rezervler için yeterince hızlı veri senkronizasyonunu ayrı ayrı soğutmak gerekir.
Sanal dosya sistemleri konusuna devam edersek: Docker Volume'lar maalesef sorunsuz değil. Genel olarak, uzun vadeli güvenilir veri depolama gibi bir konuda teknik açıdan en basit şemalarla yetinmek isterim. Ve konteynerin FS'sinden ana ana bilgisayarın FS'sine yeni bir soyutlama katmanı eklemek başlı başına bir risktir. Ancak konteynerizasyon destek sisteminin işleyişinde de bu katmanlar arasında veri aktarımında zorluklarla karşılaşıldığında durum gerçekten felaket oluyor. Şu anda, ilerleyen insanlığın bildiği sorunların çoğu ortadan kaldırılmış gibi görünüyor. Ama anlıyorsunuz ki mekanizma ne kadar karmaşıksa, kırılması da o kadar kolay oluyor.
Tüm bu "maceraların" ışığında, veritabanını tek bir yerde tutmak çok daha karlı ve kolaydır; uygulamayı konteynerleştirmeniz gerekse bile, uygulamayı kendi başına çalıştırıp dağıtım ağ geçidi aracılığıyla eş zamanlı iletişim almasına izin verin. Tek bir yerde ve tek bir yerde okunup yazılacak olan veritabanı. Bu yaklaşım, hata olasılığını ve senkronizasyonun bozulması olasılığını minimuma indirir.
Neye varıyoruz? Ayrıca, veri tabanının kapsayıcı hale getirilmesi, gerçekten ihtiyaç duyulan durumlarda uygundur. Tam uygulama veritabanını doldurup sanki iki düzine mikro hizmetiniz varmış gibi döndüremezsiniz; bu şekilde çalışmaz. Ve bunun açıkça anlaşılması gerekiyor.
Çıktı yerine
"Veritabanını sanallaştırmak ya da sanallaştırmamak" konusunda net bir sonuç bekliyorsanız, sizi hayal kırıklığına uğratacağız: burada olmayacak. Çünkü herhangi bir altyapı çözümü oluştururken moda ve ilerlemeye göre değil, öncelikle sağduyuya göre hareket etmek gerekiyor.
Kubernetis ile gelen prensip ve araçların mükemmel uyum sağladığı projeler var ve bu tür projelerde en azından arka uç alanında huzur var. Ve konteynerleştirmeye ihtiyaç duymayan, ancak normal bir sunucu altyapısına ihtiyaç duyan projeler var çünkü bunlar temelde mikro hizmet kümesi modeline yeniden ölçeklenemiyor çünkü düşecekler.
Kaynak: habr.com