Geçen yılın sonunda Rus PostgreSQL topluluğunun bir canlı yayını daha gerçekleşti Kurucu ortağı Nikolai Samokhvalov, Flant teknik direktörü Dmitry Stolyarov ile Kubernetes bağlamında bu DBMS hakkında konuştu.
Bu tartışmanın ana bölümünün bir metnini yayınlıyoruz ve şu adreste yayınlıyoruz: Yayınlanan videonun tamamı:
Veritabanları ve Kubernetes
NS: Bugün VAKUM ve KONTROL NOKTALARI hakkında konuşmayacağız. Kubernetes hakkında konuşmak istiyoruz. Uzun yıllara dayanan tecrübeniz olduğunu biliyorum. Videolarınızı izledim, hatta bazılarını tekrar izledim... Hemen asıl konuya geçelim: K8'lerde neden Postgres ya da MySQL?
DS: Bu sorunun kesin bir cevabı yoktur ve olamaz. Ancak genel olarak bu basitlik ve rahatlıktır... potansiyel. Herkes yönetilen hizmetler ister.
NS: Nasıl , sadece evde?
DS: Evet: RDS gibi, hemen her yerde.
NS: “Herhangi bir yerde” iyi bir nokta. Büyük şirketlerde her şey farklı yerlerde bulunur. O halde neden büyük bir şirketse hazır bir çözüm almıyorsunuz? Örneğin, Nutanix'in kendi geliştirmeleri var, diğer şirketler (VMware...) aynı "RDS'ye sahip, yalnızca evde."
DS: Ama sadece belirli koşullar altında çalışacak ayrı bir uygulamadan bahsediyoruz. Ve eğer Kubernetes'ten bahsediyorsak, o zaman çok çeşitli altyapılar var (ki bunlar K8'lerde olabilir). Esasen bu, buluta yönelik API'ler için bir standarttır...
NS: Ayrıca ücretsiz!
DS: O kadar önemli değil. Serbestlik, pazarın çok büyük olmayan bir kesimi için önemlidir. Önemli olan başka bir şey... Muhtemelen raporu hatırlıyorsunuzdur”"?
NS: Evet.
DS: Çok belirsiz bir şekilde karşılandığını fark ettim. Bazıları benim şunu söylediğimi düşündü: "Arkadaşlar, hadi tüm veritabanlarını Kubernetes'e taşıyalım!", bazıları ise bunların berbat bisikletler olduğuna karar verdi. Ama ben bambaşka bir şey söylemek istedim: “Bakın neler oluyor, ne sorunlar var, nasıl çözülebilir. Kubernetes veritabanlarını şimdi kullanmalı mıyız? Üretme? Eh, eğer sadece... bazı şeyleri yapmaktan hoşlanıyorsan. Ama bir geliştirici için tavsiye ettiğimi söyleyebilirim. Bir geliştirici için ortam oluşturma/silme dinamizmi çok önemlidir."
NS: Geliştirme derken, üretim olmayan tüm ortamları mı kastediyorsunuz? Aşamalandırma, Kalite Güvencesi…
DS: Mükemmel standlardan bahsediyorsak muhtemelen hayır, çünkü oradaki gereksinimler belirlidir. Hazırlama için çok büyük bir veritabanının gerekli olduğu özel durumlardan bahsediyorsak, muhtemelen hayır... Eğer bu statik, uzun ömürlü bir ortamsa, veritabanının K8'lerde bulunmasının faydası nedir?
NS: Hiçbiri. Peki statik ortamları nerede görüyoruz? Statik bir ortam yarın geçerliliğini yitirecek.
DS: Aşamalandırma statik olabilir. Müşterilerimiz var...
NS: Evet, benim de var. 10 TB'lık bir veritabanınız ve 200 GB'lık aşamalandırmanız varsa bu büyük bir sorundur...
DS: Çok güzel bir davam var! Aşamalandırmada değişikliklerin yapıldığı bir ürün veritabanı vardır. Ve bir düğme var: "Üretime geç". Bu değişiklikler - deltalar - üretimde eklenir (görünüşe göre API aracılığıyla basitçe senkronize edilmişlerdir). Bu çok egzotik bir seçenek.
NS: Vadide RDS'de ve hatta Heroku'da oturan startup'lar gördüm - bunlar 2-3 yıl öncesine ait hikayeler - ve dökümü dizüstü bilgisayarlarına indiriyorlar. Çünkü veritabanı hala sadece 80 GB ve dizüstü bilgisayarda yer var. Daha sonra herkese ek diskler satın alıyorlar, böylece farklı geliştirmeleri gerçekleştirebilecekleri 3 veritabanına sahip oluyorlar. Bu da böyle oluyor. Ayrıca prodüksiyonu sahnelemeye kopyalamaktan korkmadıklarını da gördüm; bu büyük ölçüde şirkete bağlı. Ama aynı zamanda çok korktuklarını, çoğu zaman yeterli zamanları ve elleri olmadığını da gördüm. Ancak bu konuya geçmeden önce Kubernetes hakkında bir şeyler öğrenmek istiyorum. Henüz kimsenin prod'da olmadığını doğru anlamış mıyım?
DS: Prod'da küçük veritabanlarımız var. Onlarca gigabaytlık hacimlerden ve kopyalarını yapamayacak kadar tembel olduğumuz kritik olmayan hizmetlerden bahsediyoruz (ve böyle bir ihtiyaç yok). Ve Kubernetes altında normal depolama olması şartıyla. Bu veritabanı, depolama sisteminin üstünde, koşullu olarak VMware'de sanal bir makinede çalışıyordu. Onu yerleştirdik ve artık onu makineden makineye aktarabiliriz.
NS: 100 GB'a kadar bu boyuttaki veritabanları, iyi disklerde ve iyi bir ağda birkaç dakika içinde kullanıma sunulabilir, değil mi? Saniyede 1 GB hız artık egzotik değil.
DS: Evet, doğrusal çalışma için bu bir sorun değildir.
NS: Tamam, sadece ürün hakkında düşünmemiz gerekiyor. Kubernetes'i üretim dışı ortamlar için düşünüyorsak ne yapmalıyız? Bunu Zalando'da görüyorum , Crunchy'de , başka seçenekler de var. Ve orada - bu İspanya'dan iyi dostumuz Alvaro: yaptıkları aslında sadece ve tüm dağıtım (), bunun içine Postgres'in yanı sıra bir yedek, Envoy proxy'yi de doldurmaya karar verdiler...
DS: Ne elçisi? Özellikle Postgres trafiğini dengelemek mi istiyorsunuz?
NS: Evet. Yani şöyle düşünüyorlar: Eğer bir Linux dağıtımı ve çekirdeği alırsanız, o zaman çekirdek normal PostgreSQL'dir ve bulut dostu olacak ve Kubernetes üzerinde çalışacak bir dağıtım yapmak istiyorlar. Bileşenleri (yedeklemeler vb.) bir araya getirirler ve iyi çalışmaları için bunların hatalarını ayıklarlar.
DS: Çok havalı! Esasen bu, kendi yönetilen Postgres'inizi oluşturmaya yönelik bir yazılımdır.
NS: Linux dağıtımlarının sonsuz sorunları vardır: tüm donanımların desteklenmesi için sürücülerin nasıl yapılacağı. Ve Kubernetes'te çalışacakları fikri var. Zalando operatöründe yakın zamanda AWS ile bir bağlantı gördüğümüzü biliyorum ve bu artık pek iyi değil. Belirli bir altyapıya bağlı olmak zorunda değil; o zaman ne anlamı var?
DS: Zalando'nun tam olarak nasıl bir duruma düştüğünü bilmiyorum ama Kubernetes'te depolama artık genel bir yöntem kullanarak disk yedeği almayı imkansız kılacak şekilde yapılıyor. Son zamanlarda standart olarak - en son sürümde — anlık görüntüleri mümkün kıldık ama bu nerede uygulanıyor? Doğrusunu söylemek gerekirse her şey henüz çok ham... AWS, GCE, Azure, vSphere'in üstüne CSI deniyoruz ama kullanmaya başladığınız anda henüz hazır olmadığını görüyorsunuz.
NS: Bu yüzden bazen altyapıya güvenmek zorunda kalıyoruz. Bunun hala erken bir aşama olduğunu düşünüyorum; büyüyen ağrılar. Soru: K8'lerde PgSQL'i denemek isteyen yeni başlayanlara ne gibi tavsiyelerde bulunursunuz? Hangi operatör olabilir?
DS: Sorun şu ki Postgres bizim için %3. Ayrıca Kubernetes'te çok geniş bir farklı yazılım listemiz var, her şeyi listelemeyeceğim bile. Örneğin, Elasticsearch. Çok sayıda operatör var: bazıları aktif olarak gelişiyor, diğerleri ise gelişmiyor. Operatörde ne olması gerektiğini ciddiye alabilmemiz için kendimiz için gereksinimler hazırladık. Kubernetes'e özel bir operatörde - "Amazon koşullarında bir şeyler yapacak operatörde" değil... Aslında, oldukça yaygın olarak (= neredeyse tüm istemciler) tek bir operatör kullanıyoruz - (Yakında kendisi hakkında bir makale yayınlayacağız).
NS: Peki MySQL için de değil mi? Percona'nın şu anda MySQL, MongoDB ve Postgres üzerinde çalıştığına göre, bir tür evrensel çözüm yaratmaları gerektiğini biliyorum: tüm veritabanları ve tüm bulut sağlayıcıları için.
DS: MySQL'in operatörlerine bakacak vaktimiz olmadı. Şu anda asıl odak noktamız bu değil. MySQL bağımsız olarak iyi çalışıyor. Bir veritabanını başlatabilecekseniz neden bir operatör kullanasınız ki... Postrges ile bir Docker konteyneri başlatabilir veya basit bir şekilde başlatabilirsiniz.
NS: Bu konuda da bir soru vardı. Hiç operatör yok mu?
DS: Evet, %100'ümüz PostgreSQL'i operatör olmadan çalıştırıyor. Şu ana kadar. Prometheus ve Redis için operatörü aktif olarak kullanıyoruz. Elasticsearch için bir operatör bulma planlarımız var - bu en çok "ateşli" olanıdır çünkü vakaların %100'ünde onu Kubernetes'e kurmak istiyoruz. Tıpkı MongoDB'nin de her zaman Kubernetes'te kurulu olduğundan emin olmak istediğimiz gibi. Burada belirli dilekler ortaya çıkıyor - bu durumlarda bir şeyler yapılabileceği hissi var. Postgres'e bile bakmadık. Elbette farklı seçeneklerin olduğunu biliyoruz ama aslında bağımsız bir seçeneğimiz var.
Kubernetes'te test için veritabanı
NS: Şimdi test konusuna geçelim. DevOps perspektifinden veritabanındaki değişiklikler nasıl kullanıma sunulur? Mikro hizmetler var, birçok veritabanı var, bir yerlerde sürekli bir şeyler değişiyor. DBMS perspektifinden her şeyin yolunda olması için normal CI/CD nasıl sağlanır? Yaklaşımınız nedir?
DS: Tek bir cevap olamaz. Birkaç seçenek var. Birincisi, açmak istediğimiz tabanın boyutudur. Şirketlerin prod veritabanının bir kopyasını geliştirme ve aşamada bulundurma konusunda farklı tutumlara sahip olduğundan kendiniz bahsettiniz.
NS: Ve GDPR koşullarında giderek daha dikkatli olmaya başladıklarını düşünüyorum... Avrupa'da şimdiden para cezaları uygulamaya başladıklarını söyleyebilirim.
DS: Ancak çoğu zaman üretimden bir döküm alan ve onu karıştıran bir yazılım yazabilirsiniz. Üretim verileri elde edilir (anlık görüntü, döküm, ikili kopya...), ancak anonimleştirilir. Bunun yerine oluşturma komut dosyaları olabilir: bunlar demirbaşlar veya yalnızca büyük bir veritabanı oluşturan bir komut dosyası olabilir. Sorun şu: Temel imajı oluşturmak ne kadar zaman alıyor? Peki onu istenen ortamda dağıtmak ne kadar sürer?
Bir şemaya vardık: Eğer müşterinin sabit bir veri seti varsa (veritabanının minimum versiyonu), o zaman bunları varsayılan olarak kullanırız. İnceleme ortamlarından bahsediyorsak, bir şube oluşturduğumuzda uygulamanın bir örneğini konuşlandırdık; orada küçük bir veritabanını kullanıma sunduk. Ama iyi sonuçlandı , günde bir kez (gece) üretimden bir döküm aldığımızda ve bu yüklü verileri temel alarak PostgreSQL ve MySQL ile bir Docker konteyneri oluşturduğumuzda. Bu görüntüden veritabanını 50 kat genişletmeniz gerekiyorsa, bu oldukça basit ve hızlı bir şekilde yapılır.
NS: Basit kopyalamayla mı?
DS: Veriler doğrudan Docker görüntüsünde depolanır. Onlar. Elimizde 100 GB da olsa hazır bir görsel var. Docker'daki katmanlar sayesinde bu imajı ihtiyaç duyduğumuz sayıda hızlı bir şekilde dağıtabiliyoruz. Yöntem aptalca ama işe yarıyor.
NS: Sonra test ettiğinizde Docker'ın içinde değişiyor, değil mi? Docker'ın içinde yazma üzerine kopyalama - atın ve tekrar gidin, her şey yolunda. Sınıf! Peki bunu zaten sonuna kadar kullanıyor musunuz?
DS: Uzun zamandır.
NS: Çok benzer şeyler yapıyoruz. Ancak biz Docker'ın yazma üzerine kopyalama özelliğini değil, başka bir yöntemini kullanıyoruz.
DS: Genel değil. Ve Docker her yerde çalışır.
NS: Teorik olarak evet. Ama orada modüllerimiz de var, farklı modüller yapıp farklı dosya sistemleriyle çalışabilirsiniz. Burada nasıl bir an var. Postgres tarafından tüm bunlara farklı bakıyoruz. Şimdi Docker tarafından baktım ve her şeyin işinize yaradığını gördüm. Ancak veritabanı çok büyükse, örneğin 1 TB, o zaman tüm bunlar uzun zaman alır: geceleri yapılan işlemler ve her şeyin Docker'a doldurulması... Ve eğer Docker'a 5 TB doldurulmuşsa... Yoksa her şey yolunda mı?
DS: Farkı nedir: bunlar lekelerdir, yalnızca bitler ve baytlardır.
NS: Aradaki fark şudur: bunu dump ve restore yoluyla mı yapıyorsunuz?
DS: Hiç gerekli değil. Bu görüntüyü oluşturma yöntemleri farklı olabilir.
NS: Bazı müşterilerimiz için bunu, düzenli olarak temel bir görüntü oluşturmak yerine onu sürekli güncel tutacak şekilde yaptık. Aslında bir kopyadır ancak verileri doğrudan ana bilgisayardan değil, bir arşiv aracılığıyla alır. Her gün WAL'lerin indirildiği, yedeklerinin alındığı bir ikili arşiv... Bu WAL'ler daha sonra hafif bir gecikmeyle (tam anlamıyla 1-2 saniye) temel görüntüye ulaşır. Ondan herhangi bir şekilde klonladık - artık varsayılan olarak ZFS'ye sahibiz.
DS: Ancak ZFS ile tek bir düğümle sınırlısınız.
NS: Evet. Ancak ZFS'nin aynı zamanda sihirli bir yanı da var : bununla bir anlık görüntü gönderebilirsiniz ve hatta (bunu henüz test etmedim ama...) iki şey arasında bir delta gönderebilirsiniz PGDATA. Aslında bu tür görevler için pek düşünmediğimiz başka bir aracımız daha var. PostgreSQL'in sahip olduğu , "akıllı" bir rsync gibi çalışır, izlemeniz gerekmeyen birçok şeyi atlar çünkü orada hiçbir şey değişmemiştir. İki sunucu arasında hızlı bir senkronizasyon yapıp aynı şekilde geri sarabiliriz.
Dolayısıyla, daha çok DBA açısından, sizin söylediğinizin aynısını yapmamıza olanak tanıyan bir araç yaratmaya çalışıyoruz: Bir veritabanımız var, ancak bir şeyi neredeyse aynı anda 50 kez test etmek istiyoruz.
DS: 50 kez, 50 Spot bulut sunucusu sipariş etmeniz gerektiği anlamına gelir.
NS: Hayır, her şeyi tek makinede yapıyoruz.
DS: Ama bu tek veritabanı terabayt ise nasıl 50 kat genişleteceksiniz? Büyük olasılıkla koşullu 256 GB RAM'e ihtiyacı var mı?
NS: Evet, bazen çok fazla belleğe ihtiyaç duyarsınız - bu normaldir. Ama bu hayattan bir örnek. Üretim makinesinde 96 çekirdek ve 600 GB yer alıyor. Aynı zamanda veritabanı için 32 çekirdek (hatta bazen 16 çekirdek bile) ve 100-120 GB bellek kullanılıyor.
DS: Ve oraya 50 kopya mı sığdı?
NS: Yani tek kopya var, o zaman yazarken kopyala (ZFS) çalışıyor... Daha detaylı anlatacağım.
Örneğin 10 TB’lık bir veritabanımız var. Bunun için bir disk yaptılar, ZFS de boyutunu yüzde 30-40 oranında sıkıştırdı. Yük testi yapmadığımız için kesin yanıt süresi bizim için önemli değil: 2 kata kadar daha yavaş olmasına izin verin - sorun değil.
Programcılara, QA'ya, DBA'ya vb. fırsat veriyoruz. 1-2 iş parçacığında test yapın. Örneğin, bir tür geçiş gerçekleştirebilirler. Aynı anda 10 çekirdeğe ihtiyaç duymaz; 1 Postgres arka ucuna, 1 çekirdeğe ihtiyaç duyar. Göç başlayacak - belki yine de başlayacak, ardından ikinci çekirdek kullanılacak. 16-32 çekirdeğimiz var, yani aynı anda 10 kişi çalışabiliyor, sorun yok.
Çünkü fiziksel olarak PGDATA aynı şekilde aslında Postgres'i kandırdığımız ortaya çıktı. İşin püf noktası şu: örneğin, 10 Postgres aynı anda başlatılıyor. Genellikle sorun nedir? Koydular %25 diyelim. Buna göre bu 200 GB'tır. Bunlardan üçten fazlasını başlatamayacaksınız çünkü hafıza tükenecek.
Ancak bir noktada bunun gerekli olmadığını anladık: Shared_buffers'ı 2 GB'ye ayarladık. PostgreSQL'in sahip olduğu ve gerçekte etkileyen tek şey odur . 0,5 TB’a ayarladık. Hatta gerçekte var olmamalarının da bir önemi yok; sanki varmış gibi planlar yapıyor.
Buna göre bir tür geçişi test ettiğimizde tüm planları toplayabiliriz - bunun üretimde nasıl olacağını göreceğiz. Oradaki saniyeler farklı olacak (daha yavaş), ancak gerçekte okuduğumuz veriler ve planların kendisi (hangi JOIN'lerin olduğu vb.) üretimdekiyle tamamen aynı çıkıyor. Ve bu tür birçok kontrolü tek bir makinede paralel olarak çalıştırabilirsiniz.
DS: Burada birkaç sorun olduğunu düşünmüyor musun? Birincisi yalnızca PostgreSQL'de çalışan bir çözümdür. Bu yaklaşım çok özeldir, genel değildir. İkincisi, Kubernetes'in (ve bulut teknolojilerinin artık kullanacağı her şeyin) birçok düğüm içermesi ve bu düğümlerin geçici olmasıdır. Ve sizin durumunuzda bu durum bilgisi olan, kalıcı bir düğümdür. Bunlar beni çelişkiye düşürüyor.
NS: Öncelikle katılıyorum, bu tamamen bir Postgres hikayesi. Sanırım bir tür doğrudan GÇ'miz ve neredeyse tüm bellek için bir tampon havuzumuz varsa, bu yaklaşım işe yaramayacaktır - planlar farklı olacaktır. Ama şimdilik sadece Postgres ile çalışıyoruz, başkalarını düşünmüyoruz.
Kubernetes hakkında. Siz kendiniz bize her yerde kalıcı bir veritabanımızın olduğunu söylüyorsunuz. Örnek başarısız olursa asıl önemli olan diski kaydetmektir. Burada ayrıca Kubernetes'teki platformun tamamına sahibiz ve Postgres bileşeni ayrı (gerçi bir gün orada olacak). Bu nedenle, her şey şu şekildedir: örnek düştü, ancak PV'sini kurtardık ve sanki hiçbir şey olmamış gibi onu başka bir (yeni) örneğe bağladık.
DS: Benim açımdan Kubernetes'te pod'lar oluşturuyoruz. K8s - elastik: düğümler gerektiği gibi sıralanır. Görev, basitçe bir bölme oluşturmak ve X miktarda kaynağa ihtiyacı olduğunu söylemek ve ardından K8'ler bunu kendi başına çözecektir. Ancak Kubernetes'teki depolama desteği hala kararsız: Içinde (bu sürüm yayınlandı недели önce) bu özellikler yalnızca beta haline gelir.
Altı ay ila bir yıl geçecek - aşağı yukarı istikrarlı hale gelecek veya en azından bu şekilde ilan edilecek. Daha sonra anlık görüntü alma ve yeniden boyutlandırma olanağı sorununuzu tamamen çözer. Çünkü senin bir temelin var. Evet, çok hızlı olmayabilir, ancak hız "kaputun altında" ne olduğuna bağlıdır, çünkü bazı uygulamalar disk alt sistemi düzeyinde kopyalama ve yazma üzerine kopyalama yapabilir.
NS: Ayrıca tüm motorların (Amazon, Google...) bu sürümü desteklemeye başlaması da gereklidir - bu da biraz zaman alır.
DS: Henüz kullanmıyoruz. Biz bizimkini kullanıyoruz.
Kubernetes için yerel kalkınma
NS: Tüm podları tek bir makineye kurup bu kadar küçük bir test yapmanız gerektiğinde böyle bir istekle karşılaştınız mı? Konseptin kanıtını hızlı bir şekilde elde etmek için uygulamanın Kubernetes'te çalıştığını ve bunun için çok sayıda makine tahsis edilmediğini görün. Minikube var, değil mi?
DS: Bana öyle geliyor ki - tek bir düğüme konuşlandırılan - bu durum yalnızca yerel kalkınma ile ilgili. Veya böyle bir modelin bazı tezahürleri. Yemek yemek orada , . Kubernetes IN Docker'ı kullanmaya doğru ilerliyoruz. Şimdi testler için onunla çalışmaya başladık.
NS: Bunun tüm bölmeleri tek bir Docker görüntüsüne sarma girişimi olduğunu düşünürdüm. Ancak bunun tamamen farklı bir şeyle ilgili olduğu ortaya çıktı. Her neyse, Docker'da ayrı kaplar, ayrı bölmeler var.
DS: Evet. Ve oldukça komik bir taklit yapılmış, ama anlamı şu... Dağıtım için bir yardımcı programımız var - . Bunu koşullu mod haline getirmek istiyoruz werf up: “Bana yerel Kubernetes'i bulun.” Ve sonra oradaki koşulu çalıştırın werf follow. Daha sonra geliştirici IDE'yi düzenleyebilecek ve sistemde değişiklikleri gören, görüntüleri yeniden oluşturan ve bunları yerel K8'lere yeniden dağıtan bir süreç başlatılacak. Yerel kalkınma sorununu bu şekilde çözmeye çalışmak istiyoruz.
K8'in gerçekliğinde anlık görüntüler ve veritabanı klonlama
NS: Yazarak kopyalamaya dönersek. Bulutların da anlık görüntüleri olduğunu fark ettim. Farklı çalışıyorlar. Örneğin, GCP'de: Amerika Birleşik Devletleri'nin doğu kıyısında çok terabaytlık bir örneğiniz var. Periyodik olarak anlık görüntüler çekersiniz. Batı kıyısındaki diskin bir kopyasını anlık görüntüden alırsınız - birkaç dakika içinde her şey hazırdır, çok hızlı çalışır, yalnızca önbelleğin hafızada doldurulması gerekir. Ancak bu klonlar (anlık görüntüler) yeni bir birimi 'tedarik etmek' içindir. Çok sayıda örnek oluşturmanız gerektiğinde bu harika bir şey.
Ancak testler için bana öyle geliyor ki, sizin Docker'da bahsettiğiniz veya benim ZFS'de, btrfs'de ve hatta LVM'de bahsettiğim anlık görüntüler, tek bir makinede gerçekten yeni veriler oluşturmanıza izin vermiyor. Bulutta, yine de her seferinde onlar için ödeme yapacaksınız ve saniyeler değil, dakikalar (ve bu durumda , muhtemelen bir saat).
Bunun yerine, bu verileri bir veya iki saniye içinde alıp testi çalıştırabilir ve çöpe atabilirsiniz. Bu anlık görüntüler farklı sorunları çözer. İlk durumda - ölçeği büyütmek ve yeni kopyalar almak için ve ikincisinde - testler için.
DS: Katılmıyorum. Birim klonlamanın düzgün çalışmasını sağlamak bulutun görevidir. Uygulamalarına bakmadım ama donanımda bunu nasıl yaptığımızı biliyorum. Ceph'imiz var, her türlü fiziksel hacme izin veriyor () söylemek clone ve onlarca milisaniye içinde aynı özelliklere sahip ikinci bir cilt elde edin, 'ami, vb. İçerisinde yazarken kopyalamanın zor olduğunu anlamalısınız. Bulut neden aynısını yapmasın? Öyle ya da böyle bunu yapmaya çalıştıklarına eminim.
NS: Ancak bir örneği yükseltmek, Docker'ı oraya getirmek vb. yine de saniyeler, onlarca saniye sürecektir.
DS: Bir örneğin tamamını yükseltmek neden gereklidir? 32 çekirdekli bir örneğimiz var, 16... ve buna sığabilir - örneğin dört. Beşinciyi sipariş ettiğimizde örnek zaten yükseltilmiş olacak ve ardından silinecektir.
NS: Evet ilginç, Kubernetes'in bambaşka bir hikaye olduğu ortaya çıkıyor. Veritabanımız K8’lerde değil ve elimizde tek bir örnek var. Ancak çok terabaytlık bir veritabanını klonlamak iki saniyeden fazla sürmez.
DS: Bu harika. Ancak başlangıç noktam bunun genel bir çözüm olmadığıdır. Evet, harika ama yalnızca Postgres için ve yalnızca bir düğümde uygundur.
NS: Sadece Postgres için uygun değil: anlattığım gibi bu planlar sadece içinde işe yarayacak. Ancak planlarla ilgilenmiyorsak ve yalnızca işlevsel test için tüm verilere ihtiyacımız varsa, o zaman bu herhangi bir DBMS için uygundur.
DS: Yıllar önce LVM anlık görüntülerinde benzer bir şey yapmıştık. Bu bir klasik. Bu yaklaşım çok aktif olarak kullanıldı. Durum bilgisi olan düğümler sadece bir acıdır. Çünkü onları elinizden bırakmamalı, her zaman hatırlamalısınız...
NS: Burada hibrit olma ihtimalini görüyor musunuz? Diyelim ki durum bilgisi bir tür kapsül, birkaç kişi (birçok test kullanıcısı) için çalışıyor. Bir birimimiz var ama dosya sistemi sayesinde klonlar yerel. Pod düşerse ancak disk kalırsa, kapsül yükselecek, tüm klonlar hakkındaki bilgileri sayacak, her şeyi tekrar toplayacak ve şunu söyleyecektir: "İşte bu bağlantı noktalarında çalışan klonlarınız, onlarla çalışmaya devam edin."
DS: Teknik olarak bu, Kubernetes içinde birçok Postgres'i çalıştırdığımız tek bir bölme olduğu anlamına gelir.
NS: Evet. Onun da bir sınırı var; diyelim ki onunla aynı anda 10'dan fazla kişi çalışmıyor. Eğer 20'ye ihtiyacınız varsa böyle ikinci bir kapsülü başlatacağız. İkinci tam hacmi aldıktan sonra onu tamamen klonlayacağız, aynı 10 "ince" klona sahip olacak. Bu fırsatı görmüyor musun?
DS: Buraya güvenlik konularını eklememiz gerekiyor. Bu tür bir organizasyon, bu bölmenin yüksek ayrıcalıklara (yeteneklere) sahip olduğunu ima eder, çünkü dosya sistemi üzerinde standart dışı işlemler gerçekleştirebilir... Ancak tekrar ediyorum: Orta vadede Kubernetes'teki depolamayı düzelteceklerine inanıyorum ve bulutlar tüm hikayeyi ciltlerle düzeltecekler - her şey "sadece işe yarayacak". Yeniden boyutlandırma olacak, klonlama olacak... Bir cilt var - "Buna göre yeni bir tane oluştur" diyoruz ve bir buçuk saniye sonra ihtiyacımız olanı elde ediyoruz.
NS: Birçok terabayt için bir buçuk saniyeye inanmıyorum. Ceph'te bunu kendin yapıyorsun ama bulutlardan bahsediyorsun. Buluta gidin, EC2'de çok terabaytlık bir EBS biriminin klonunu oluşturun ve performansın ne olacağını görün. Birkaç saniye sürmeyecek. Bu seviyeye ne zaman ulaşacaklarını çok merak ediyorum. Ne dediğini anlıyorum ama farklı düşünüyorum.
DS: Tamam ama orta vadede dedim, kısa vadede değil. Birkaç yıldır.
Zalando'dan PostgreSQL operatörü hakkında
Toplantının ortasında Zalando'dan eski bir geliştirici olan Alexey Klyukin de katıldı ve PostgreSQL operatörünün geçmişi hakkında konuştu:
Bu konuya genel olarak değinilmesi harika: hem Postgres hem de Kubernetes. 2017 yılında Zalando'da bunu yapmaya başladığımızda herkesin yapmak istediği ama kimsenin yapmadığı bir konuydu. Herkesin zaten Kubernetes'i vardı, ancak veritabanlarıyla ne yapılacağı sorulduğunda insanlar bile şunu beğendi: K8'lerin vaazını veren şöyle bir şey söyledi:
“Yönetilen hizmetlere gidin ve bunları kullanın, veritabanını Kubernetes'te çalıştırmayın. Aksi takdirde K8'leriniz örneğin yükseltme yapmaya, tüm düğümleri kapatmaya karar verecek ve verileriniz çok çok uzaklara uçacak."
Bu tavsiyenin aksine Kubernetes'te Postgres veritabanını başlatacak bir operatör yapmaya karar verdik. Ve iyi bir nedenimiz vardı - . Bu, PostgreSQL için doğru şekilde yapılan otomatik bir yük devretmedir; küme hakkındaki bilgilerin depolanması için etcd, consul veya ZooKeeper'ın kullanılması. Öyle bir depo ki, örneğin mevcut liderin ne olduğunu soran herkese aynı bilgiyi verecek - her şeyi dağıtmış olmamıza rağmen - böylece beyin bölünmesi olmayacak. Artı elimizde onun için.
Genel olarak şirketin otomatik yük devretme ihtiyacı, dahili donanım veri merkezinden buluta geçiş sonrasında ortaya çıktı. Bulut, tescilli bir PaaS (Hizmet Olarak Platform) çözümüne dayanıyordu. Açık Kaynaktır, ancak onu çalışır duruma getirmek çok fazla çalışma gerektirdi. çağrıldı .
Başlangıçta Kubernetes yoktu. Daha doğrusu bizim kendi çözümümüz devreye girdiğinde K8'ler zaten mevcuttu ama o kadar hamdı ki üretime uygun değildi. Bana göre 2015 ya da 2016 yılıydı. 2017 yılına gelindiğinde Kubernetes az çok olgunlaşmıştı; oraya taşınmaya ihtiyaç vardı.
Ve zaten bir Docker konteynerimiz vardı. Docker'ı kullanan bir PaaS vardı. Neden K8'leri denemiyorsunuz? Neden kendi operatörünüzü yazmıyorsunuz? Avito'dan aramıza gelen Murat Kabilov, kendi inisiyatifiyle "oynamak" için bunu bir proje olarak başlattı ve proje "başladı".
Ama genel olarak AWS'den bahsetmek istedim. Neden AWS ile ilgili tarihsel kodlar vardı?
Kubernetes'te bir şeyi çalıştırdığınızda K8'lerin böyle bir çalışma olduğunu anlamalısınız. Sürekli gelişiyor, gelişiyor ve hatta zaman zaman bozuluyor. Kubernetes'teki tüm değişiklikleri yakından takip etmeniz, bir şey olursa derinlemesine incelemeye hazır olmanız ve nasıl çalıştığını ayrıntılı olarak - belki de istediğinizden daha fazla - öğrenmeniz gerekiyor. Bu prensip olarak veritabanlarınızı çalıştırdığınız her platform için geçerlidir...
Yani, açıklamayı yaptığımızda, Postgres'i harici bir birim üzerinde çalıştırıyorduk (bu durumda, AWS üzerinde çalıştığımız için EBS). Veritabanı büyüdü, bir noktada yeniden boyutlandırmak gerekiyordu: örneğin, EBS'nin başlangıçtaki boyutu 100 TB'ydi, veritabanı büyüdü, şimdi EBS'yi 200 TB yapmak istiyoruz. Nasıl? Diyelim ki yeni bir örnekte döküm/geri yükleme işlemi yapabilirsiniz ancak bu uzun zaman alacak ve kesinti gerektirecektir.
Bu nedenle, EBS bölümünü büyütecek ve ardından dosya sistemine yeni alanı kullanmasını bildirecek bir yeniden boyutlandırma istedim. Biz de bunu yaptık ama o zamanlar Kubernetes'in yeniden boyutlandırma işlemi için herhangi bir API'si yoktu. AWS üzerinde çalıştığımız için API'sinin kodunu yazdık.
Kimse sizi aynısını diğer platformlar için yapmaktan alıkoyamaz. Açıklamada yalnızca AWS üzerinde çalıştırılabileceğine, diğer her şeyde çalışmayacağına dair bir ipucu bulunmuyor. Genel olarak bu bir Açık Kaynak projesidir: Yeni API'nin kullanımının ortaya çıkmasını hızlandırmak isteyen varsa memnuniyetle karşılarız. Yemek yemek , çekme talepleri - Zalando ekibi bunlara oldukça hızlı yanıt vermeye ve operatörü tanıtmaya çalışıyor. Bildiğim kadarıyla proje Google Summer of Code ve diğer bazı benzer girişimlerde. Zalando bunun üzerinde çok aktif bir şekilde çalışıyor.
PS Bonusu!
PostgreSQL ve Kubernetes konusuyla ilgileniyorsanız, lütfen Nikolai ile konuştuğum bir sonraki Postgres Salı gününün geçen hafta gerçekleştiğini unutmayın. Zalando'dan Alexander Kukushkin. Ondan video mevcut .
PPS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com