Veritabanının bir docker kapsayıcısında dağıtılması neden önerilmez?
Önsöz
Docker son iki yılda çok popüler oldu.Geliştiriciler tüm uygulamaları ve yazılımları bir Docker konteynerinde dağıtmak için sabırsızlanıyorlar, ancak veritabanını konteynerde dağıtmak istediğinizden emin misiniz?
Bu soru bir kurgu değil, çünkü internette birçok işletim kılavuzu ve video öğretici var.Editör, veritabanının sizin referansınız için konteynırlaştırmaya uygun olmadığının bazı nedenlerini çözdü.Aynı zamanda, onu kullanırken daha dikkatli olmanızı umuyorum.
Şimdiye kadar, veritabanını konteyner haline getirmek çok mantıksız, ancak konteynerleştirmenin avantajları tüm geliştiricilerin tatlılığı tattığına inanıyor ve teknolojinin gelişmesiyle daha mükemmel çözümlerin ortaya çıkabileceğini umuyor.
Docker'ın veritabanı dağıtımı için uygun olmamasının 7 nedeni
1. Veri güvenliği sorunları
Verileri konteynerlerde saklamayın. Bu aynı zamanda resmi Docker konteyner kullanım ipuçlarından biridir. Konteyner herhangi bir zamanda durdurulabilir veya silinebilir. Kap kapalı olduğunda, kaptaki veriler kaybolacaktır. Veri kaybını önlemek için, kullanıcılar verileri depolamak için veri birimi bağlamayı kullanabilir. Bununla birlikte, konteynerin Birimler tasarımı, Union FS yansıtma katmanı etrafında kalıcı depolama sağlamaktır ve veri güvenliğinin garantileri yoktur. Kap aniden çökerse ve veritabanı normal şekilde kapatılmazsa, veriler zarar görebilir. Ayrıca konteynerdeki paylaşılan veri hacmi grubu, fiziksel makinenin donanımına da zarar verecektir.
Docker verilerini ana bilgisayarda depolamak isteseniz bile, yine de verilerin kaybolmayacağını garanti edemez. Docker birimleri, Union FS görüntü katmanı etrafında kalıcı depolama sağlamak için tasarlanmıştır, ancak yine de garantileri yoktur.
Mevcut depolama sürücüleriyle Docker hala güvenilmez olma riski altındadır. Konteyner çökerse ve veritabanı düzgün kapatılmazsa, veriler bozulabilir.
2. Performans sorunları
MySQL'in ilişkisel bir veritabanı olduğunu ve yüksek IO gerektirdiğini herkes bilir. Fiziksel bir makine birden fazla çalıştığında, GÇ birikerek GÇ darboğazına neden olur ve MySQL'in okuma ve yazma performansını büyük ölçüde azaltır.
Docker Uygulamasının On Zorluğu ile ilgili özel bir oturumda, devlete ait bir bankanın mimarı da şunları söyledi: "Veritabanının performans darboğazı genellikle IO'da görünür. Docker fikrini izlerseniz, birden fazla docker son GÇ isteği olacaktır. Depolamada göründü. Artık İnternet veritabanı çoğunlukla hiçbir şeyi paylaşmayan bir mimaridir, belki de bu Docker'a geçişi dikkate almayan bir faktördür. "
Performans problemleri için, bazı öğrencilerin ilgili çözümleri de olabilir:
(1) Veritabanı programı ile verilerin ayrılması
MySQL'i çalıştırmak için Docker kullanırsanız, veritabanı programı ve verilerin ayrılması gerekir, veriler paylaşılan depoda depolanır ve program konteynere yerleştirilir. Kap anormalse veya MySQL hizmeti anormalse, yepyeni bir kapsayıcı otomatik olarak başlatılır. Ek olarak, verilerin ana bilgisayarda saklanmaması önerilir Ana bilgisayar ve konteyner, birim grubunu paylaşır, bu da ana bilgisayarın hasarı üzerinde daha büyük bir etkiye sahip olacaktır.
(2) Hafif veya dağıtılmış bir veritabanı çalıştırın
Docker'da hafif veya dağıtılmış veritabanları dağıtan Docker, konteyner hizmetini yeniden başlatmaya devam etmek yerine hizmetin kapatmasını ve yeni kapsayıcıları otomatik olarak başlatmasını önerir.
(3) Makul yerleşim uygulaması
Yüksek IO gereksinimleri olan uygulamalar veya hizmetler için, veritabanını fiziksel bir makinede veya KVM'de dağıtmak daha uygundur. Şu anda TX Cloudun TDSQLi ve Alinin Oceanbasei Docker yerine doğrudan fiziksel makinelerde dağıtılmaktadır.
3. Ağ sorunları
Docker ağını anlamak için, ağ sanallaştırma konusunda derin bir anlayışa sahip olmanız gerekir. Ayrıca beklenmedik durumlarla başa çıkmak için hazırlıklı olmalısınız. Destek veya ek araçlar olmadan hataları düzeltmeniz gerekebilir.
Biliyoruz ki: veritabanları daha yüksek yükler elde etmek için özel ve dayanıklı iş hacmine ihtiyaç duyar. Ayrıca kabın, hiper yönetici ve ana makine sanal makinenin arkasındaki bir izolasyon katmanı olduğunu da biliyoruz. Bununla birlikte, ağ, ana ve yardımcı veritabanları arasında 24/7 istikrarlı bir bağlantı gerektiren veritabanı replikasyonu için gereklidir. Çözülmemiş Docker ağ sorunu 1.9 sürümünde çözülmedi.
Bu sorunları bir araya getirdiğimizde konteynerleştirme, veritabanı konteynerlerinin yönetilmesini zorlaştırır. En iyi mühendis olduğunuzu ve herhangi bir sorunun çözülebileceğini biliyorum. Ancak Docker ağ sorunlarını çözmek için ne kadar zaman harcamanız gerekiyor? Veritabanını özel bir ortama koymak daha iyi olmaz mı? Gerçekten önemli olan iş hedeflerine odaklanmak için zaman kazanın.
4. Durum
Docker'da kapsayıcıların düzenlenmesini gerçekleştirebilen ve tek hata noktası sorununu çözebilen durum bilgisi olmayan bir hizmeti paketlemek harika. Peki veritabanı ne olacak? Veritabanını aynı ortama koyun, durum bilgisi olacak ve sistem arızasının kapsamını genişletecektir. Uygulama örneğiniz veya uygulamanızın bir sonraki çöküşünde veritabanı etkilenebilir.
Bilgi noktaları Docker'da yatay ölçeklendirme, veritabanları için değil, yalnızca durum bilgisiz bilgi işlem hizmetleri için kullanılabilir.
Docker'ın hızlı genişlemesinin önemli bir özelliği vatansızlıktır.Veri durumuna sahip olanlar doğrudan Docker'a yerleştirilmeye uygun değildir. Docker'da bir veritabanı kurulursa, depolama hizmetlerinin ayrıca sağlanması gerekir.
Şu anda, TX Cloud'un TDSQL (Finansal Dağıtılmış Veritabanı) ve Alibaba Cloud'un Oceanbase (Dağıtılmış Veritabanı Sistemi), yönetimi kolay olan Docker'da değil, doğrudan fiziksel makinelerde çalışıyor.
5. Kaynak izolasyonu
Kaynak izolasyonu açısından, Docker gerçekten de sanal makine KVM'den daha düşüktür.Docker, kaynak kısıtlamalarını uygulamak için Cgroup kullanır. Yalnızca maksimum kaynak tüketimini sınırlayabilir, ancak diğer programları kendi kaynaklarını kullanmaktan ayıramaz. Diğer uygulamalar fiziksel makine kaynaklarını aşırı derecede işgal ederse, konteynerdeki MySQL'in okuma ve yazma verimliliğini etkileyecektir.
Ne kadar fazla izolasyon seviyesine ihtiyacınız olursa, o kadar fazla ek kaynak elde edersiniz. Özel ortamlarla karşılaştırıldığında, kolay yatay ölçeklendirme Docker'ın büyük bir avantajıdır. Ancak Docker'da yatay ölçekleme yalnızca durum bilgisi olmayan bilgi işlem hizmetleri için kullanılabilir ve veritabanları geçerli değildir.
Veritabanı için herhangi bir izolasyon işlevi görmüyoruz, öyleyse neden onu konteynere koymalıyız?
6. Bulut platformlarının uygulanamazlığı
Çoğu insan projelere paylaşılan bulut üzerinden başlar. Bulut, sanal makine çalıştırma ve değiştirmenin karmaşıklığını basitleştirir, böylece yeni donanım ortamlarını kimsenin çalışmadığı gece veya hafta sonları test etmeye gerek kalmaz. Bir örneği hızlı bir şekilde başlatabildiğimizde, bu örneğin çalıştığı ortam hakkında neden endişelenmemiz gerekiyor?
Bu nedenle bulut sağlayıcılara çok fazla ücret ödüyoruz. Örnek için bir veritabanı konteyneri yerleştirdiğimizde, yukarıda bahsedilen kolaylık mevcut değildir. Veriler eşleşmediğinden, yeni örnek mevcut örnekle uyumlu olmayacaktır. Örneğin bağımsız hizmetleri kullanmasını kısıtlamak istiyorsanız, DB'nin kapsayıcıya alınmamış bir ortam kullanmasına izin vermelisiniz. Yalnızca bilgi işlem hizmet katmanı için esnek olarak genişleme yeteneğini ayırmamız gerekir.
7. Veritabanını çalıştırmak için çevresel gereklilikler
Genellikle DBMS kapsayıcısının ve diğer hizmetlerin aynı ana bilgisayarda çalıştığı görülür. Ancak bu hizmetlerin çok farklı donanım gereksinimleri vardır.
Veritabanlarının (özellikle ilişkisel veritabanları) IO için daha yüksek gereksinimleri vardır. Genellikle veritabanı motorları, eşzamanlı kaynaklar için rekabeti önlemek için özel bir ortam kullanır. Veritabanınızı bir konteynere koyarsanız, projenizin kaynaklarını boşa harcarsınız. Çünkü bu örnek için birçok ek kaynak yapılandırmanız gerekiyor. Genel bulutta, 34G belleğe ihtiyacınız olduğunda, başlattığınız bulut sunucusu 64G belleğe sahip olmalıdır. Uygulamada bu kaynaklar tam olarak kullanılmamaktadır.
Nasıl başa çıkılır bununla? Hiyerarşik olarak tasarlayabilir ve farklı seviyelerde birden çok örneği başlatmak için sabit kaynakları kullanabilirsiniz. Yatay genişleme her zaman dikey genişlemeden daha iyidir.
sonuç olarak
Yukarıdaki soruya yanıt olarak, veritabanının bir konteynerde konuşlandırılmaması gerektiği anlamına mı geliyor?
Cevap hayır
Veri kaybına duyarlı olmayan hizmetleri (arama, gömme noktaları) sayısallaştırabilir ve örnek sayısını artırmak için veritabanı parçalamayı kullanabilir, böylece verimi artırabiliriz.
Docker, hafif veya dağıtılmış veritabanları çalıştırmak için uygundur. Docker hizmeti kilitlendiğinde, konteyner hizmetini yeniden başlatmaya devam etmek yerine otomatik olarak yeni bir kapsayıcı başlatır.
Veritabanı, birden çok düğümü otomatik olarak ölçeklendirmek, tolere etmek, değiştirmek ve getirmek için ara yazılım ve kapsayıcılı sistemler kullanır ve ayrıca kapsayıcıya alınabilir.
