Yüksek Kullanılabilirlikli OpenStack Ağ Oluşturma: Uygulamalar ve Öğrenilen Dersler

TSAI

Bir TSAI mühendisi, şirketin OpenStack kullanarak yüksek kullanılabilirlikli bir ağ mimarisini nasıl uyguladığını açıklıyor. OpenStack kullanarak şirket içi özel bir bulut çözümü oluşturmak ve işletmek isteyen kuruluşlar için dikkate alınması gereken en önemli hususlardan biri ağdır. Dağıtımlar ölçeklendikçe, performans, operasyonel istikrar ve güvenilirliğin karmaşıklıkları da artar. Aşağıda, TSAI mühendisi Tony Walker, bir uygulayıcının bakış açısından şirketin kurumsal ölçekte ve ötesinde dağıtım için uygun yüksek kullanılabilirlikli bir ağ mimarisini nasıl uyguladığını açıklıyor.

TSAI özel bulutunu oluşturmaya başladığında, OpenStack ile "hazır" olarak makul bir şekilde karşılayamayacağımız bazı temel hedeflerimiz/amaçlarımız vardı, bu yüzden kendi çözümümüzü uygulamaya karar verdik. O zamandan beri, yalnızca OpenStack projesinden (bkz. Dağıtılmış Sanal Yönlendirici) değil, aynı zamanda tescilli çözümlerde uzmanlaşmış satıcılardan da özel çözümler oluşturmaya ve çalıştırmaya yönelik birçok alternatif ortaya çıktı.

Ağ ve OpenStack

Bulut ağ mimarimizi düşünmeye başladığımızda, bizim için üç şey kritikti:

Kullanıcılar, ortamımızdaki her yerden erişilebilen "gerçek" IP'lere sahip kiracı ağları oluşturabilmelidir.
Kiracı ağları, tek bir arıza noktası olmadan yüksek düzeyde kullanılabilir olmalıdır.
OpenStack ağ performansı mümkün olduğunca çıplak metale yakın olmalıdır.
Gelenekselden Yüksek Kullanılabilirliğe Geçiş

Erken dönemde yapılması gereken bir seçim, hangi ağ izolasyon teknolojisinin kullanılacağıdır. Birden fazla sunucu rafından oluşan bir dağıtım çalıştırıyorsanız, bunlar büyük olasılıkla ayrı Katman 2 ağ etki alanlarında bulunacaktır (en azından bizim için bu bilinçli bir seçimdi). Bu durumda, mevcut tek gerçek seçenek bir "kaplama" sağlayıcısı kullanmaktır. Bunu yapmak, OpenStack ağlarının birden fazla Katman 2 etki alanına yayılmasına olanak tanır ve bu da size yüksek kullanılabilirlik çözümü yapılandırmak için ihtiyaç duyduğunuz ilk yapı taşını sağlar. Kaplama protokolü olarak VXLAN'ı seçtik, çünkü NIC'ler kapsülleme/kapsülden çıkarma işleminin donanım yükünü kaldırmasını destekler. Hesaplamalı ağır kaldırmayı NIC donanımına taşıma yeteneğinden yararlanarak, yalnızca yazılıma dayalı standart bir kuruluma göre yaklaşık 4 kat performans iyileştirmesi elde edebildik.

VXLAN ile, OpenStack kullanıcılarının kendi ağlarını oluşturabilecekleri büyük bir ağ bloğuyla başlayabilirsiniz (başlamak için /20'yi seçtik). Vanilla OpenStack, kullanıcıların ağ oluştururken keyfi IP aralıkları belirlemesine olanak tanır; bu, sabit bloklar kullanıldığında işleri karmaşıklaştırabilir. Bu nedenle, yalnızca bu işlevi engellemekle kalmayıp, aynı zamanda bu aralıktan bir sonraki kullanılabilir alt ağı otomatik olarak seçen bir hizmet de uygulamak istedik. Daha sonra HA yapılandırmasının ilk aşamasını düzenlemek için ayrı bir hizmet benimsedik.

Her yeni ağ oluşturulduğunda, iki mantıksal yönlendirici (Neutron ağ geçitleri) bağlanır ve bu ağa bağlanır. Her yönlendirici farklı bir rafta bulunur ve harici ağ geçidi ağına bağlanır, böylece sanal makinelere yedekli bağlantı sağlanır.

Dağıtım Stratejisi

Başlangıçta kaç tane Neutron ağ geçidinin dağıtılacağına ve nereye dağıtılacağına karar vermek oldukça basittir. En azından, temel HA gereksinimlerini karşılamak için birden fazla rafa yayılmış iki Neutron ağ geçidi düğümü olmalıdır. Başka bir seçenek, her bir işlem düğümünde Neutron L3 aracısını çalıştırmaktır; bu, yük kümedeki daha fazla düğüme dağıtıldıkça ağ performansını önemli ölçüde iyileştirecektir. Ancak, üst katman ağları ve Neutron ağ geçitleri yeni bir karmaşıklık düzeyi getirmiştir ve düğüm başına bir ağ geçidinin yönetilmesinin, maliyetlerin faydalardan daha ağır bastığı noktaya kadar karmaşıklığı artıracağına inanıyoruz. Kiracı ağlarının sayısı ve işlem düğümlerinin sayısı arttıkça, ağ geçitlerini de ölçeklendirmeniz gerekecektir. Raf başına üç ila altı Neutron ağ geçidi çalıştırmanın, yedeklilik, performans ve karmaşıklık arasında iyi bir denge sağladığını bulduk.

İleriye Bakış

Bu teoride kulağa harika gelse de, ağ ad alanını işlem düğümlerine etkili bir şekilde kopyalamak, özellikle bir operasyon ve bakım perspektifinden, beraberinde bir sürü yeni endişe ve husus getirir. Sınırlı sayıda Neutron ağ geçidiyle sorun giderme zorsa, bu sayıyı her bölgedeki işlem düğümleriyle çarpma fikri akıl almazdır. Ayrıca, bu anlamda, her düğümün bir yönlendirici gibi davranması, artan hesaplama kullanımı ve ağ yığınıyla uğraşırken çekişme gibi diğer yan etkilere yol açar. Örneğin, yeni VM'ler başlatılırken gereken ek yük ile ilgili sorunlar da vardır. Tüm hesaplama düğümlerindeki ARP tabloları, tüm olası girdilerle önceden doldurulur, bu da bir kiracı ağındaki tüm hesaplama düğümlerinin tablolarının her zaman senkronize olması gerektiği anlamına gelir, bu da performans cezalarına neden olabilir ve ölçekte keşfedilmesi zaman alır.

Openstack ağ alanında, onu dağıtmaya başladığımızdan beri birçok ilginç gelişme oldu ve bunları keşfetmeyi dört gözle bekliyoruz Önümüzdeki olasılıkları ve zorlukları ortaya koyun.