Optimum Ağ Yapılandırmalarıyla MinIO'dan En İyi Şekilde Yararlanın - İşte Nasıl Yapılacağı

MinIO, birden fazla fiziksel veya sanal makinenin bilgi işlem ve depolama kaynaklarının kaynaklarını verimli bir şekilde kullanan dağıtılmış bir şekilde dağıtılabilir. Bu, Amazon Web Hizmetleri, Google Bulut Platformu, Microsoft'un Azure platformu ve diğerleri gibi özel veya genel bir bulut ortamında çalışan MinIO olabilir. MinIO çeşitli topoloji türlerine dağıtılabilir; üretimde Çok Düğümlü Çoklu Sürücü (MNMD) dağıtımını öneriyoruz. MinIO, kullanım durumunuza göre tasarlayıp optimize edebileceğiniz tek site dağıtımınız için BC/DR düzeyinde yük devretme ve kurtarma desteği sağlamak üzere site çoğaltmasını önerir.

Önceki bir blog yazımızda MinIO dağıtımınız için donanım seçerken kullanabileceğiniz en iyi uygulamalardan bazılarını zaten tartışmıştık. En iyi bölgeyi seçmek, doğru sürücüyü, CPU ve bellek yapılandırmalarını ve hatta önerilen bazı ağ yapılandırmalarını seçmek gibi donanımın çeşitli yönlerine değindik. Sistem tasarımı için çok sayıda farklı en iyi uygulamalara değinmiş olsak da, her zaman daha derine inebiliriz ve bugün MinIO'yu sürücülerden ve ağlardan en iyi performansı elde edecek şekilde tasarlamanın bazı ince noktalarına değineceğiz.

Bu blog yazısında, MinIO'yu, verilerinizin birden fazla MinIO dağıtımında verimli bir şekilde depolanmasını ve erişilmesini sağlamak için kullanılabilecek farklı çoğaltma stratejilerine ve ağ topolojilerine göre yapılandırabileceğiniz ağ yapılandırmalarının derinliklerine ineceğiz. Bağlantılı/Çift NIC kurulumu gibi (ek yük getiren) herhangi bir karmaşık yapılandırma yapmanıza gerek yoktur.

Basit Ağ Stratejileri

MinIO, bulutta yerel hizmetler için S3 uyumlu bir depolama arka ucudur. Genel olarak ağ trafiğinin uygulamalar ile küme arasında veya kümedeki düğümler arasında olduğunu düşünüyoruz. Düğümler arası trafik nedeniyle, düğümler arasındaki ağ oluşturmanın mümkün olduğu kadar hızlı olması çok önemlidir. Her havuz, kendi silme kümelerine sahip bağımsız bir düğüm grubundan oluşur. MinIO, okuma ve yazma işlemlerini yönlendirdiği doğru silme kümesini belirlemek için her havuzu sorgulamalıdır; böylece her ek havuz, çağrı başına minimum düzeyde ancak artan düğümler arası trafik ekler. Doğru silme kümesini içeren havuz, uygulamaya tamamen şeffaf kalarak işleme yanıt verir.

İşletmenin 1 GbE veya 10 GbE NIC'lerle idare edebildiği günler geride kaldı. Modern kurumsal iş yükü ideal olarak 100 GbE NIC'leri kullanır. TCP protokolünün fizik ve ek yük sınırlamaları göz önüne alındığında, bu NIC'lerin mevcut bant genişliğinin %80-90'ını, genellikle 100 Gbps NIC'ler için 10 GB/s civarında, gerçekten iyi hazırlanmış ağlarda 12 GB/s'ye kadar sunması beklenir. MinIO, tüm arayüzleri dinlediği için bant genişliğinden yararlanmak için herhangi bir ek ağ yapılandırmasına ihtiyaç duymaz. MinIO, kutudan çıktığı haliyle birden fazla ağ arabiriminde (NIC) dinlemeyi destekler.

MinIO ağı için başka herhangi bir özel konfigürasyona ihtiyacınız yoktur, ancak isteğe bağlı olarak daha önce tartıştığımız bazı ağ temellerini kullanarak MinIO trafiğini belirli bir arayüz üzerinden yönlendirebilirsiniz.

Bu örnekte, göstermek için bir Linux işletim sistemi kullanacağız ancak hangi işletim sistemini kullanırsanız kullanın ağ oluşturma temelleri aynıdır. Uygulama, ağ yapılandırmasına bağlı olarak biraz farklılık gösterebilir ancak bu size bir fikir verecektir.

İlk önce rota tablosunu listeleyerek başlayacağız

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

MinIO sunucularınızı 10.56.98.16/28 CIDR aralığında olacak şekilde yapılandırdıysanız, diyelim ki MinIO düğümünün IP adreslerinden biri 10.56.98.21'dir ve bu adres eth0 arayüzü üzerinden yönlendirilecektir çünkü /28, 10.56'nın yönlendirme tablosu girişiyle eşleşir. 0,98,0/24.

Ancak MinIO trafiğini eth0 yerine eth1 üzerinden yönlendirmek istiyorsanız MinIO CIDR için belirli bir rota eklememiz gerekir; böylece bu alt ağla eşleşen tüm trafik, söz konusu belirli ağ arayüzü üzerinden yönlendirilir.

 $ ip route add 10.56.98.16/28 dev eth1

Rota eklendikten sonra nasıl göründüğünü görmek için yönlendirme tablosunu tekrar listeleyelim.

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

Şimdi /28 CIDR için bir rota görüyoruz. MinIO düğümü 10.56.98.21'e ping atarsanız artık eth1 arayüzü aracılığıyla yönlendirilecektir. Bunun nedeni, /24'ün /28 ile çakıştığı iki rota olduğunda, genellikle en uzun öneki olan rotaya tercih verilmesi (bu durumda /28) ve trafiği yönlendirirken diğer kısa önek rotalarına göre öncelikli olmasıdır. Buna en uzun eşleşen önek kuralı denir.

10.56.98.21'e ping atarak 10.56.98.16/28 trafiğinin uygun şekilde yönlendirildiğini doğrulayabilir ve ardından aşağıdaki gibi tcpdump'ı kontrol edebilirsiniz. 10.56.98.18 kaynağından gelen trafiğin eth1 üzerinden 10.56.98.21'e yönlendirildiğini fark edeceksiniz.

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

MinIO'da görebileceğiniz gibi, trafik ayrımını sağlamak için hiçbir ek özel bağlantı noktasına veya hizmete ihtiyaç yoktur. MinIO, basitlik göz önünde bulundurularak tasarlanmıştır ve bu durumda, bir ağ geçidi hizmeti gibi karmaşık bir şey tasarlamak yerine her zaman oluşturma ve satın almayı düşünüyoruz; MinIO, aynı sonucu çok az ek yük ile elde etmek için işletim sistemi katmanında zaten mevcut olan ağ oluşturma temellerini kullanır. olası.

Bu fikri bir adım daha ileriye taşıyabiliriz. Günümüzde sunucular, daha fazlasını ekleme seçeneğine sahip en az 2 arayüze sahiptir. Dolayısıyla, uygulama trafiğinin MinIO ile aynı arayüzlerden geçmesini sağlamak yerine, uygulamanızın ayrı bir CIDR bloğunda da çalışmasını sağlayabilirsiniz (uygulama boyutunuza uygun bir blok seçin). Bu ayırma, MinIO trafiğinin çoğaltma ve yeniden dengeleme için uygulamanın performansını etkilememesini ve bunun tersinin de geçerli olmasını sağlar. Ayrıca, MinIO'nun performansını etkilemeden işlemlerini gerçekleştirmek için her zaman ihtiyaç duyduğu kapasiteye ve bant genişliğine sahip olmasını sağlamak için trafiği izleme ve izleme olanağı da sağlar.

Peki ya farklı sitelerde veya bölgelerde MinIO'nuz varsa? Performans darboğazları olmadığından emin olmak için bunu etkili bir şekilde nasıl yapılandırabilirsiniz? MinIO'nun mevcut en katı kullanım durumlarından bazıları için sunduğu birkaç farklı türde çoğaltma yapılandırması vardır.

Çoğaltma stratejilerinin en verimlilerinden biri siteden siteye çoğaltmadır. Bu, MinIO'yu tek bir küme ile başlatmanıza ve ihtiyaç arttıkça N sayısına genişletmenize olanak tanır. 3 farklı sitede çalışan bir ETL/ELT uygulamanız olduğunu varsayalım. Genellikle veriler yalnızca bölgelerden birinde mevcuttur ve diğer bölgelerin, işlemlerini yürütmek için bölgeler arasında çok büyük miktarda veri çekmesi gerekir. Söylemeye gerek yok, bu sadece son derece verimsiz olmakla kalmıyor, aynı zamanda ağ altyapısı üzerinde muazzam bir baskı oluşturuyor ve WAN'ı paylaşan diğer uygulamalar için potansiyel olarak darboğazlara neden oluyor.

Siteden siteye çoğaltma yapılandırmasında verileri yalnızca ilk sitedeki MinIO kümesine yazarsınız. Çoğaltma işlemi, verileri otomatik olarak diğer sitelere kopyalayacaktır. ETL/ELT uygulamasında yapılması gereken ek bir değişiklik yoktur. Her sitedeki işleri, Nginx gibi bir ters proxy tarafından desteklenen ilgili MinIO kümesine yönlendirmeniz yeterlidir; okumalar, aşağıda gösterildiği gibi bölgeler arasında WAN üzerinden olduğundan çok daha hızlı olacaktır.

Ancak bu şu soruyu akla getiriyor: Trafiğe daha fazla ince ayar yapmak mümkün mü? Diyelim ki veri dosyasını site 1'e eklediniz, günün saati ne olursa olsun onu hemen diğer sitelere kopyalayacaktır. Bu, belki de diğer ETL/ELT işlerinin çalıştığı ve aynı zamanda bir sonraki grubun çalıştırılmasının beklendiği ertesi güne kadar kullanılamayacak verileri kopyalamak için ağ kaynaklarının kullanıldığı zirve sırasında olabilir. Bu durumda ne yapılabilir? MinIO'nun Toplu Çoğaltma özelliğinin kullanışlı olduğu yer burasıdır. Toplu çoğaltma, belirli bir zamanda çoğaltmak istediğiniz veri türünü seçip seçmenize olanak tanır; tamamen yapılandırılabilir. Bu durumda toplu çoğaltma işi, trafiğin en düşük olduğu çalışma saatleri dışında çalışacak şekilde ayarlanabilir. Uygulama erişim süreleri gün, hafta ve hatta ay boyunca değişebileceğinden, MinIO ağ trafiğini izlemenin kullanışlı olduğu yer burasıdır, böylece toplu işinizi tam olarak doğru zamanda çalışacak şekilde yapılandırabilirsiniz. Küresel olarak dağıtılmış bir MinIO nesne deposunda BC/DR veya coğrafi yerel okuma/yazma performansı gibi işlevleri desteklemek için eş siteleri farklı raflara, veri merkezlerine veya coğrafi bölgelere dağıtabilirsiniz.

Son düşünceler

Özetlemek gerekirse, MinIO'nun ağ mimarisi piyasadaki en basit ve anlaşılır mimarilerden biridir. Tekerleği yeniden icat etmek yerine MinIO, hata ayıklamanın neredeyse imkansız olduğu karmaşık ağ ve ağ geçidi kurulumuna sahip diğer bazı veri depolarıyla eşitlik sağlamak için ağ oluşturma temellerini kullanır. Aynı sorunda ne kadar hata ayıklarsanız ayıklayın, mimarinin karmaşık doğası nedeniyle ilk defa karşılaşıyormuşsunuz gibi hissedeceksiniz. Bunun yerine MinIO, uygulama geliştiricisinin yükünü veri çoğaltmayı sürdürmekten uzaklaştıran ve daha ziyade verileri depolamaya ve işlemeye odaklanan daha yüksek düzeyde soyutlamalara odaklanır.

Her zamanki gibi, MinIO Ağ yapılandırması veya nasıl kurulacağı hakkında sorularınız varsa Slack üzerinden bizimle iletişime geçmeyi unutmayın veya daha iyisi SUBNET aboneliğine kaydolun!