Bulut bilişim hayatımızın derinliklerine nüfuz ediyor ve muhtemelen herhangi bir bulut hizmetini en az bir kez kullanmamış tek bir kişi bile yoktur. Ancak bulutun tam olarak ne olduğunu ve nasıl çalıştığını fikir düzeyinde bile çok az kişi biliyor. 5G halihazırda bir gerçeklik haline geliyor ve telekom altyapısı, tıpkı tamamen donanım çözümlerinden sanallaştırılmış "sütunlara" geçtiğinde olduğu gibi, kutup çözümlerinden bulut çözümlerine geçmeye başlıyor.
Bugün bulut altyapısının iç dünyasından bahsedeceğiz, özellikle ağ kısmının temellerine bakacağız.
Bulut nedir? Aynı sanallaştırma - profil görünümü?
Mantıksal bir sorudan daha fazlası. Hayır - bu sanallaştırma değildir, ancak onsuz yapılamaz. İki tanıma bakalım:
Bulut bilişim (bundan sonra Bulut olarak anılacaktır) Servis sağlayıcı için mümkün olan en düşük gecikme süresi ve minimum maliyetle talep üzerine dağıtılması ve başlatılması gereken dağıtılmış bilgi işlem kaynaklarına kullanıcı dostu erişim sağlayan bir modeldir.
sanallaştırma - bu, bir fiziksel varlığı (örneğin bir sunucu) birkaç sanal varlığa bölme yeteneğidir, böylece kaynakların kullanımını artırır (örneğin, yüzde 3-25 oranında yüklenmiş 30 sunucunuz vardı, sanallaştırmadan sonra 1 sunucu yüklediniz) yüzde 80-90). Doğal olarak sanallaştırma kaynakların bir kısmını tüketir - hipervizörü beslemeniz gerekir, ancak uygulamanın gösterdiği gibi oyun her şeye değer. Sanallaştırmanın ideal bir örneği, sanal makineleri mükemmel bir şekilde hazırlayan VMWare veya örneğin benim tercih ettiğim KVM'dir, ancak bu bir zevk meselesi.
Sanallaştırmayı farkına varmadan kullanıyoruz ve hatta demir yönlendiriciler bile zaten sanallaştırmayı kullanıyor - örneğin, JunOS'un en son sürümünde işletim sistemi, gerçek zamanlı bir Linux dağıtımının (Wind River 9) üzerine sanal bir makine olarak kurulur. Ancak sanallaştırma bulut değildir ancak bulut, sanallaştırma olmadan var olamaz.
Sanallaştırma, bulutun üzerine inşa edildiği yapı taşlarından biridir.
Birkaç hipervizörü tek bir L2 alanına toplayarak bir bulut oluşturmak, vlan'ları bir tür yanıtlayıcı aracılığıyla otomatik olarak kaydetmek için birkaç yaml oyun kitabı eklemek ve otomatik olarak sanal makineler oluşturmak için bunların üzerine bir orkestrasyon sistemi gibi bir şey sıkıştırmak işe yaramayacaktır. Daha doğru olacak ama sonuçta ortaya çıkan Frankenstein, diğerlerinin nihai hayali olsa da ihtiyacımız olan bulut değil. Üstelik aynı Openstack'ı alırsanız, aslında yine Frankenstein'dır, ama neyse, şimdilik bunun hakkında konuşmayalım.
Ancak yukarıda sunulan tanımdan, aslında bulut olarak adlandırılabilecek şeyin tam olarak net olmadığını anlıyorum.
Bu nedenle, NIST'in (Ulusal Standartlar ve Teknoloji Enstitüsü) bir belgesi, bir bulut altyapısının sahip olması gereken 5 ana özelliği sunmaktadır:
Talep üzerine hizmet verilmektedir. Kullanıcıya kendisine tahsis edilen bilgisayar kaynaklarına (ağlar, sanal diskler, bellek, işlemci çekirdekleri vb.) ücretsiz erişim hakkı verilmeli ve bu kaynaklar otomatik olarak yani servis sağlayıcının müdahalesine gerek kalmadan sağlanmalıdır.
Geniş hizmet kullanılabilirliği. Kaynaklara erişim, hem standart PC'lerin hem de ince istemcilerin ve mobil cihazların kullanımına izin verecek şekilde standart mekanizmalarla sağlanmalıdır.
Kaynakları havuzlarda birleştirmek. Kaynak havuzları, aynı anda birden fazla müşteriye kaynak sağlayabilmeli, müşterilerin yalıtılmış olmasını ve kaynaklar için karşılıklı etki ve rekabetten uzak olmasını sağlamalıdır. Havuzlara ağlar da dahil edilmiştir, bu da örtüşen adresleme kullanma olasılığını gösterir. Havuzlar talebe göre ölçeklenebilmelidir. Havuzların kullanılması, gerekli düzeyde kaynak hatası toleransının ve fiziksel ve sanal kaynakların soyutlanmasının sağlanmasını mümkün kılar - hizmetin alıcısına talep ettiği kaynak seti basitçe sağlanır (bu kaynaklar fiziksel olarak nerede bulunur, kaç tane kaynak bulunur). sunucular ve anahtarlar - istemci için fark etmez). Ancak sağlayıcının bu kaynakların şeffaf bir şekilde rezervasyonunu sağlaması gerektiği gerçeğini dikkate almalıyız.
Farklı koşullara hızlı adaptasyon. Hizmetler esnek olmalı - kaynakların hızlı sağlanması, yeniden dağıtılması, müşterinin isteği üzerine kaynakların eklenmesi veya azaltılması ve müşteri açısından bulut kaynaklarının sonsuz olduğu hissi olmalıdır. Anlamayı kolaylaştırmak için, örneğin, sunucudaki sabit sürücünün bozulması nedeniyle Apple iCloud'daki disk alanınızın bir kısmının kaybolduğuna dair bir uyarı görmüyorsunuz ve sürücüler de bozulabilir. Ayrıca sizin açınızdan bu hizmetin olanakları neredeyse sınırsızdır - 2 TB'ye ihtiyacınız var - sorun değil, ödediniz ve aldınız. Benzer bir örneği Google.Drive veya Yandex.Disk ile vermek mümkündür.
Sunulan hizmeti ölçme imkanı. Bulut sistemleri tüketilen kaynakları otomatik olarak kontrol etmeli ve optimize etmeli ve bu mekanizmaların hem kullanıcı hem de hizmet sağlayıcı için şeffaf olması gerekir. Yani, sizin ve müşterilerinizin ne kadar kaynak tükettiğini her zaman kontrol edebilirsiniz.
Bu gereksinimlerin çoğunlukla genel buluta yönelik gereksinimler olduğu gerçeğini dikkate almakta fayda var; dolayısıyla özel bir bulut (yani şirketin iç ihtiyaçları için başlatılan bir bulut) için bu gereksinimler biraz ayarlanabilir. Ancak yine de bunların yapılması gerekiyor, aksi takdirde bulut bilişimin tüm avantajlarından yararlanamayacağız.
Neden bir buluta ihtiyacımız var?
Ancak herhangi bir yeni veya mevcut teknoloji, herhangi bir yeni protokol bir şey için yaratılır (tabii ki RIP-ng hariç). Hiç kimsenin bir protokol uğruna bir protokole ihtiyacı yoktur (tabii ki RIP-ng hariç). Bulutun kullanıcıya/istemciye bir tür hizmet sağlamak için yaratılması mantıklıdır. Hepimiz Dropbox veya Google.Docs gibi en az birkaç bulut hizmetine aşinayız ve çoğu insanın bunları başarılı bir şekilde kullandığına inanıyorum; örneğin, bu makale Google.Docs bulut hizmeti kullanılarak yazılmıştır. Ancak bildiğimiz bulut hizmetleri, bulutun yeteneklerinin yalnızca bir parçasıdır; daha doğrusu yalnızca SaaS türü bir hizmettir. Bulut hizmetini üç şekilde sağlayabiliriz: SaaS, PaaS veya IaaS şeklinde. Hangi hizmete ihtiyacınız olduğu isteklerinize ve yeteneklerinize bağlıdır.
Her birine sırayla bakalım:
Hizmet Olarak Yazılım (SaaS) müşteriye tam teşekküllü bir hizmet (örneğin, Yandex.Mail veya Gmail gibi bir e-posta hizmeti) sağlamaya yönelik bir modeldir. Bu hizmet sağlama modelinde, bir müşteri olarak aslında hizmetleri kullanmak dışında hiçbir şey yapmazsınız; yani hizmeti ayarlamayı, hata toleransını veya yedekliliğini düşünmenize gerek kalmaz. Önemli olan şifrenizden ödün vermemek; bu hizmetin sağlayıcısı gerisini sizin için halledecektir. Servis sağlayıcı açısından bakıldığında, sunucu donanımı ve ana bilgisayar işletim sistemlerinden veritabanı ve yazılım ayarlarına kadar tüm hizmetten tamamen sorumludur.
Hizmet Olarak Platform (PaaS) — bu modeli kullanırken, servis sağlayıcı müşteriye servis için bir iş parçası sağlar; örneğin bir Web sunucusunu ele alalım. Servis sağlayıcı, müşteriye bir sanal sunucu (aslında RAM/CPU/Depolama/Ağlar vb. gibi bir dizi kaynak) sağladı ve hatta işletim sistemini ve gerekli yazılımı bu sunucuya kurdu, ancak yapılandırma tüm bunlar müşterinin kendisi tarafından ve müşterinin yanıtladığı hizmetin performansı için yapılır. Hizmet sağlayıcı, önceki durumda olduğu gibi, fiziksel ekipmanın performansından, hipervizörlerden, sanal makinenin kendisinden, ağın kullanılabilirliğinden vb. sorumludur, ancak hizmetin kendisi artık kendi sorumluluk alanında değildir.
Hizmet Olarak Altyapı (IaaS) - bu yaklaşım zaten daha ilginçtir, aslında, servis sağlayıcı müşteriye tam bir sanallaştırılmış altyapı sağlar - yani CPU Çekirdekleri, RAM, Ağlar vb. gibi bir dizi kaynak (havuz). müşteri - müşterinin tahsis edilen havuz (kota) dahilinde bu kaynaklarla ne yapmak istediği - tedarikçi için özellikle önemli değildir. Müşterinin kendi vEPC'sini oluşturmak, hatta bir mini operatör oluşturup iletişim hizmetleri sağlamak isteyip istemediğine şüphe yok - bunu yapın. Böyle bir senaryoda, hizmet sağlayıcı kaynakların sağlanmasından, bunların hata toleransından ve kullanılabilirliğinden ve ayrıca bu kaynakların bir havuzda toplanmasına ve kaynakları herhangi bir zamanda artırma veya azaltma olanağıyla bunları istemcinin kullanımına sunmalarına olanak tanıyan işletim sisteminden sorumludur. müşterinin isteği üzerine. İstemci, ağların kurulumu da dahil olmak üzere (harici ağlar hariç) tüm sanal makineleri ve diğer cicili bicili, self servis portalı ve konsolu aracılığıyla kendisi yapılandırır.
OpenStack nedir?
Her üç seçenekte de servis sağlayıcının bulut altyapısı oluşturulmasını sağlayacak bir işletim sistemine ihtiyacı vardır. Aslında SaaS ile birden fazla bölüm tüm teknoloji yığınından sorumludur - altyapıdan sorumlu olan bir bölüm vardır - yani başka bir bölüme IaaS sağlar, bu bölüm müşteriye SaaS sağlar. OpenStack, bir grup anahtar, sunucu ve depolama sistemini tek bir kaynak havuzunda toplamanıza, bu ortak havuzu alt havuzlara (kiracılara) ayırmanıza ve bu kaynakları ağ üzerinden istemcilere sağlamanıza olanak tanıyan bulut işletim sistemlerinden biridir.
OpenStack standart kimlik doğrulama mekanizmalarını kullanarak API aracılığıyla sağlanan ve yönetilen büyük bilgi işlem kaynakları havuzlarını, veri depolamayı ve ağ kaynaklarını kontrol etmenize olanak tanıyan bir bulut işletim sistemidir.
Başka bir deyişle, bu, bulut hizmetleri (hem genel hem de özel) oluşturmak için tasarlanmış bir dizi ücretsiz yazılım projesidir - yani sunucu ve anahtarlama ekipmanını tek bir kaynak havuzunda birleştirmenize, yönetmenize olanak tanıyan bir dizi araç. Bu kaynaklar, gerekli düzeyde hata toleransını sağlar.
Bu materyalin yazıldığı sırada OpenStack yapısı şöyle görünüyordu:
Fotoğrafın alındığı yer
OpenStack'ta bulunan bileşenlerin her biri belirli bir işlevi yerine getirir. Bu dağıtılmış mimari, ihtiyaç duyduğunuz işlevsel bileşenler kümesini çözüme dahil etmenize olanak tanır. Bununla birlikte, bazı bileşenler kök bileşenlerdir ve bunların çıkarılması, çözümün bir bütün olarak tamamen veya kısmen çalışamaz hale gelmesine yol açacaktır. Bu bileşenler genellikle şu şekilde sınıflandırılır:
- Kullanıcı Paneli — OpenStack hizmetlerini yönetmek için web tabanlı GUI
- Kilit taşı diğer hizmetler için kimlik doğrulama ve yetkilendirme işlevselliği sağlamanın yanı sıra kullanıcı kimlik bilgilerini ve rollerini yöneten merkezi bir kimlik hizmetidir.
- Nötron - çeşitli OpenStack hizmetlerinin arayüzleri arasında bağlantı sağlayan bir ağ hizmeti (VM'ler arasındaki bağlantı ve bunların dış dünyaya erişimi dahil)
- kül — sanal makineler için blok depolamaya erişim sağlar
- yeni — sanal makinelerin yaşam döngüsü yönetimi
- Bakış — sanal makine görüntüleri ve anlık görüntüleri deposu
- Hızlı — depolama nesnesine erişim sağlar
- Ceilometre — telemetri toplama ve mevcut ve tüketilen kaynakları ölçme yeteneği sağlayan bir hizmet
- ısı — kaynakların otomatik olarak oluşturulması ve sağlanması için şablonlara dayalı orkestrasyon
Tüm projelerin tam listesi ve amaçları görüntülenebilir .
Her OpenStack bileşeni, belirli bir işlevi gerçekleştiren ve bu işlevi yönetmek için bir API sağlayan ve birleşik bir altyapı oluşturmak için diğer bulut işletim sistemi hizmetleriyle etkileşime giren bir hizmettir. Örneğin Nova, bilgi işlem kaynak yönetimi ve bu kaynakların yapılandırılmasına erişim için bir API sağlar; Glance, görüntü yönetimi ve bunları yönetmek için bir API sağlar; Cinder, blok depolama ve onu yönetmek için bir API vb. sağlar. Tüm işlevler birbirine çok yakın bir şekilde bağlıdır.
Ancak ona bakarsanız, OpenStack'te çalışan tüm hizmetlerin sonuçta ağa bağlı bir tür sanal makine (veya konteyner) olduğunu görürsünüz. Soru ortaya çıkıyor: neden bu kadar çok öğeye ihtiyacımız var?
Openstack'ta sanal bir makine oluşturmak ve onu ağa ve kalıcı depolamaya bağlamak için algoritmayı inceleyelim.
- İster Horizon (Dashboard) aracılığıyla ister CLI aracılığıyla bir istek olsun, bir makine oluşturmak için bir istek oluşturduğunuzda, gerçekleşen ilk şey isteğinizin Keystone'da yetkilendirilmesidir - bir makine oluşturabilir misiniz, makinede şu özellikler var mı? Bu ağı kullanma hakkınız, taslak kotanız vb.
- Keystone isteğinizi doğrular ve yanıt mesajında daha sonra kullanılacak bir kimlik doğrulama belirteci oluşturur. Keystone'dan yanıt alındıktan sonra istek Nova'ya (nova api) gönderilir.
- Nova-api, önceden oluşturulmuş kimlik doğrulama jetonunu kullanarak Keystone ile iletişime geçerek isteğinizin geçerliliğini kontrol eder.
- Keystone, kimlik doğrulama işlemini gerçekleştirir ve bu kimlik doğrulama belirtecine dayalı olarak izinler ve kısıtlamalar hakkında bilgi sağlar.
- Nova-api, nova-database'de yeni VM için bir giriş oluşturur ve makineyi oluşturma isteğini nova-scheduler'a iletir.
- Nova-scheduler, belirtilen parametrelere, ağırlıklara ve bölgelere göre VM'nin konuşlandırılacağı ana bilgisayarı (bilgisayar düğümü) seçer. Bunun ve VM ID'nin bir kaydı nova veritabanına yazılır.
- Daha sonra nova-scheduler, bir örneği dağıtma isteği ile nova-compute ile iletişime geçer. Nova-compute, makine parametreleri hakkında bilgi almak için nova-conductor ile iletişim kurar (nova-conductor, nova-veritabanı ile nova-bilgisayar arasında proxy sunucusu görevi gören ve veritabanıyla ilgili sorunları önlemek için nova-veritabanına yönelik istek sayısını sınırlayan bir nova öğesidir) tutarlılık yükünün azaltılması).
- Nova-conductor, istenen bilgiyi nova-veri tabanından alır ve nova-compute'a iletir.
- Daha sonra nova-comput çağrıları görüntü kimliğini almak için göz atar. Glace, Keystone'daki isteği doğrular ve istenen bilgiyi döndürür.
- Nova-comput, ağ parametreleri hakkında bilgi almak için nötronla iletişim kurar. Bakışa benzer şekilde, neutron Keystone'daki isteği doğrular, ardından veritabanında bir giriş (port tanımlayıcı vb.) oluşturur, bir port oluşturmak için bir istek oluşturur ve istenen bilgiyi nova-compute'a döndürür.
- Nova-compute, sanal makineye bir birim tahsis etme isteğiyle cürufla iletişime geçer. Bakışa benzer şekilde elma şarabı, Keystone'daki isteği doğrular, bir birim oluşturma isteği oluşturur ve istenen bilgiyi döndürür.
- Nova-compute, belirtilen parametrelere sahip bir sanal makine dağıtma isteği ile libvirt ile iletişim kurar.
Aslında, basit bir sanal makine oluşturma gibi basit görünen bir işlem, bulut platformunun öğeleri arasında böylesine bir API çağrıları girdabına dönüşüyor. Üstelik gördüğünüz gibi daha önce belirlenen hizmetler bile aralarında etkileşimin gerçekleştiği daha küçük bileşenlerden oluşuyor. Bir makine oluşturmak, bulut platformunun yapmanıza izin verdiği şeylerin yalnızca küçük bir kısmıdır; trafiği dengelemekten sorumlu bir hizmet, blok depolamadan sorumlu bir hizmet, DNS'den sorumlu bir hizmet, çıplak donanım sunucularının sağlanmasından sorumlu bir hizmet vb. vardır. Bulut, sanal makinelerinize (sanallaştırmanın aksine) koyun sürüsü gibi davranmanıza olanak tanır. Sanal ortamda makinenize bir şey olursa - onu yedeklerden vb. geri yüklersiniz, ancak bulut uygulamaları sanal makinenin o kadar önemli bir rol oynamayacağı şekilde inşa edilmiştir - sanal makine "öldü" - sorun değil - yeni bir araç oluşturuldu, araç şablona dayanıyor ve dedikleri gibi ekip, savaşçının kaybını fark etmedi. Doğal olarak bu, düzenleme mekanizmalarının varlığını sağlar - Heat şablonlarını kullanarak düzinelerce ağ ve sanal makineden oluşan karmaşık bir işlevi kolayca dağıtabilirsiniz.
Ağ olmadan bulut altyapısının olmadığını her zaman akılda tutmakta fayda var - her öğe şu ya da bu şekilde ağ aracılığıyla diğer öğelerle etkileşime giriyor. Ayrıca bulutun kesinlikle statik olmayan bir ağı vardır. Doğal olarak, alt katman ağı az çok statiktir - her gün yeni düğümler ve anahtarlar eklenmez, ancak katman bileşeni sürekli olarak değişebilir ve kaçınılmaz olarak değişecektir - yeni ağlar eklenecek veya silinecek, yeni sanal makineler görünecek ve eskileri değişecek ölmek. Ve yazının başında verilen bulut tanımından da hatırlayacağınız gibi, kaynakların kullanıcıya otomatik olarak ve en az (veya daha iyisi, servis sağlayıcının müdahalesine gerek kalmadan) tahsis edilmesi gerekiyor. Yani, http/https aracılığıyla erişilebilen kişisel hesabınız biçiminde bir ön uç biçiminde mevcut olan ağ kaynaklarının sağlanması ve arka uç olarak görevdeki ağ mühendisi Vasily bir bulut değildir, hatta Vasily'nin sekiz eli varsa.
Neutron, bir ağ hizmeti olarak, bulut altyapısının ağ bölümünü yönetmek için bir API sağlar. Hizmet, Hizmet Olarak Ağ (NaaS) adı verilen bir soyutlama katmanı sağlayarak Openstack'ın ağ oluşturma bölümünü güçlendirir ve yönetir. Yani ağ, örneğin sanal CPU çekirdekleri veya RAM miktarıyla aynı sanal ölçülebilir birimdir.
Ancak OpenStack'in ağ kısmının mimarisine geçmeden önce bu ağın OpenStack'te nasıl çalıştığına ve ağın neden bulutun önemli ve ayrılmaz bir parçası olduğuna bakalım.
Yani iki KIRMIZI istemci VM'miz ve iki YEŞİL istemci VM'miz var. Bu makinelerin iki hipervizör üzerinde şu şekilde konumlandığını varsayalım:
Şu anda bu sadece 4 sunucunun sanallaştırılmasıdır, başka bir şey değildir, çünkü şu ana kadar yaptığımız tek şey 4 sunucuyu sanallaştırıp onları iki fiziksel sunucuya yerleştirmek oldu. Ve şu ana kadar ağa bile bağlı değiller.
Bulut oluşturmak için birkaç bileşen eklememiz gerekir. Öncelikle ağ kısmını sanallaştırıyoruz; bu 4 makineyi çiftler halinde bağlamamız gerekiyor ve istemciler L2 bağlantısı istiyor. Bir anahtar kullanabilir ve bir hattı kendi yönünde yapılandırabilir ve her şeyi bir linux köprüsü veya daha ileri düzey kullanıcılar için openvswitch kullanarak çözebilirsiniz (buna daha sonra döneceğiz). Ancak çok fazla ağ olabilir ve L2'yi sürekli olarak bir anahtara göndermek en iyi fikir değildir; farklı departmanlar, bir hizmet masası, bir uygulamanın tamamlanması için aylarca beklemek, haftalarca sorun giderme süreci vardır - modern dünyada bu yaklaşımı artık işe yaramıyor. Ve bir şirket bunu ne kadar erken anlarsa ilerlemesi o kadar kolay olur. Bu nedenle, hipervizörler arasından sanal makinelerimizin iletişim kuracağı bir L3 ağı seçeceğiz ve bu L3 ağının üzerine, sanal makinelerimizin trafiğinin çalışacağı sanal L2 yer paylaşımlı ağlar kuracağız. Kapsülleme olarak GRE, Geneve veya VxLAN kullanabilirsiniz. Şimdilik ikincisine odaklanalım, her ne kadar pek önemli olmasa da.
VTEP'i bir yere yerleştirmemiz gerekiyor (Umarım herkes VxLAN terminolojisine aşinadır). Doğrudan sunuculardan gelen bir L3 ağımız olduğundan hiçbir şey VTEP'yi sunucuların kendilerine yerleştirmemizi engelleyemez ve OVS (OpenvSwitch) bunu yapmada mükemmeldir. Sonuç olarak şu tasarımı elde ettik:
VM'ler arasındaki trafiğin bölünmesi gerektiğinden sanal makinelere giden bağlantı noktaları farklı vlan numaralarına sahip olacaktır. Etiket numarası yalnızca bir sanal anahtarda rol oynar, çünkü VxLAN'da kapsüllendiğinde onu kolayca kaldırabiliriz, çünkü bir VNI'ye sahip olacağız.
Artık onlar için makinelerimizi ve sanal ağlarımızı sorunsuz bir şekilde oluşturabiliyoruz.
Ancak, istemcinin başka bir makinesi varsa ancak farklı bir ağdaysa ne olur? Ağlar arasında rootlamaya ihtiyacımız var. Merkezi yönlendirme kullanıldığında basit bir seçeneğe bakacağız - yani trafik, özel olarak ayrılmış ağ düğümleri aracılığıyla yönlendirilir (kural olarak, bunlar kontrol düğümleriyle birleştirilir, bu nedenle aynı şeye sahip olacağız).
Karmaşık bir şey yok gibi görünüyor - kontrol düğümünde bir köprü arayüzü oluşturuyoruz, trafiği ona yönlendiriyoruz ve oradan onu ihtiyacımız olan yere yönlendiriyoruz. Ancak sorun şu ki, KIRMIZI istemci 10.0.0.0/24 ağını kullanmak istiyor ve YEŞİL istemci 10.0.0.0/24 ağını kullanmak istiyor. Yani adres alanlarını kesiştirmeye başlıyoruz. Ek olarak, istemciler diğer istemcilerin kendi iç ağlarına yönlendirilmesini istemezler ki bu da mantıklıdır. Ağları ve istemci veri trafiğini ayırmak için her birine ayrı bir ad alanı tahsis edeceğiz. Ad alanı aslında Linux ağ yığınının bir kopyasıdır; yani RED ad alanındaki istemciler, YEŞİL ad alanındaki istemcilerden tamamen yalıtılmıştır (yani, bu istemci ağları arasındaki yönlendirmeye varsayılan ad alanı aracılığıyla veya yukarı akış aktarım ekipmanı üzerinden izin verilir).
Yani aşağıdaki diyagramı elde ederiz:
L2 tünelleri tüm bilgi işlem düğümlerinden kontrol düğümüne doğru birleşir. Bu ağlar için L3 arayüzünün bulunduğu düğüm, her biri izolasyon için özel bir ad alanında bulunur.
Ancak en önemli şeyi unuttuk. Sanal makinenin istemciye bir hizmet sağlaması, yani kendisine ulaşılabilecek en az bir harici arayüze sahip olması gerekir. Yani dış dünyaya çıkmamız gerekiyor. Burada farklı seçenekler var. En basit seçeneği yapalım. Her istemciye, sağlayıcının ağında geçerli olacak ve diğer ağlarla çakışmayacak bir ağ ekleyeceğiz. Ağlar aynı zamanda sağlayıcı ağı tarafında kesişebilir ve farklı VRF'lere bakabilir. Ağ verileri ayrıca her istemcinin ad alanında da bulunacaktır. Ancak yine de tek bir fiziksel (veya daha mantıklı olan bağ) arayüz aracılığıyla dış dünyaya çıkacaklar. İstemci trafiğini ayırmak için dışarıya giden trafik, istemciye tahsis edilen bir VLAN etiketi ile etiketlenecektir.
Sonuç olarak şu diyagramı elde ettik:
Makul bir soru, neden bilgi işlem düğümlerinin kendileri üzerinde ağ geçitleri yapmayalım? Bu büyük bir sorun değil, üstelik dağıtılmış yönlendiriciyi (DVR) açarsanız bu işe yarayacaktır. Bu senaryoda, Openstack'ta varsayılan olarak kullanılan merkezi ağ geçidine sahip en basit seçeneği düşünüyoruz. Yüksek yüklü işlevler için hem dağıtılmış yönlendirici hem de SR-IOV ve Passthrough gibi hızlandırma teknolojilerini kullanacaklar, ancak dedikleri gibi bu tamamen farklı bir hikaye. Öncelikle işin temel kısmını ele alalım, sonra detaylara geçeceğiz.
Aslında planımız zaten uygulanabilir, ancak birkaç nüans var:
- Makinelerimizi bir şekilde korumamız yani istemciye doğru anahtar arayüzüne bir filtre koymamız gerekiyor.
- Sanal makinenin otomatik olarak bir IP adresi almasını mümkün kılın, böylece her seferinde konsol aracılığıyla oturum açmanıza ve adresi kaydetmenize gerek kalmaz.
Makineleri korumakla başlayalım. Bunun için banal iptables kullanabilirsiniz, neden olmasın.
Yani artık topolojimiz biraz daha karmaşık hale geldi:
Hadi devam edelim. Bir DHCP sunucusu eklememiz gerekiyor. Her istemci için DHCP sunucularını bulmak için en ideal yer, yukarıda bahsedilen ve ad alanlarının bulunduğu kontrol düğümüdür:
Ancak küçük bir sorun var. Ya her şey yeniden başlatılırsa ve DHCP'de adres kiralamayla ilgili tüm bilgiler kaybolursa? Makinelere yeni adreslerin verilmesi mantıklı, bu da pek uygun değil. Buradan çıkmanın iki yolu var - ya alan adlarını kullanın ve her istemci için bir DNS sunucusu ekleyin, o zaman adres bizim için özellikle önemli olmayacaktır (k8s'deki ağ kısmına benzer şekilde) - ancak harici ağlarda bir sorun var çünkü adresler DHCP aracılığıyla da verilebilir - bulut platformundaki DNS sunucuları ve harici bir DNS sunucusuyla senkronizasyona ihtiyacınız var ki bu bence çok esnek değil ama oldukça mümkün. Veya ikinci seçenek meta verileri kullanmaktır; yani, makine zaten bir adres almışsa DHCP sunucusunun makineye hangi adresi vereceğini bilmesi için makineye verilen adres hakkındaki bilgileri kaydetmektir. İkinci seçenek, araçla ilgili ek bilgileri kaydetmenize olanak tanıdığı için daha basit ve daha esnektir. Şimdi diyagrama aracı meta verilerini ekleyelim:
Tartışmaya değer başka bir konu da tüm istemciler tarafından tek bir harici ağ kullanma yeteneğidir, çünkü harici ağlar, tüm ağ boyunca geçerli olmaları gerekiyorsa zor olacaktır - bu ağların tahsisini sürekli olarak tahsis etmeniz ve kontrol etmeniz gerekir. Tüm istemciler için önceden yapılandırılmış tek bir harici ağı kullanma yeteneği, genel bir bulut oluştururken çok faydalı olacaktır. Bu, makinelerin konuşlandırılmasını kolaylaştıracaktır çünkü bir adres veritabanına başvurmamıza ve her müşterinin harici ağı için benzersiz bir adres alanı seçmemize gerek yoktur. Ek olarak, harici bir ağı önceden kaydedebiliriz ve dağıtım sırasında yalnızca harici adresleri istemci makinelerle ilişkilendirmemiz gerekecektir.
Ve burada NAT yardımımıza koşuyor; NAT çevirisini kullanarak müşterilerin varsayılan ad alanı aracılığıyla dış dünyaya erişmesini mümkün kılacağız. Peki, burada küçük bir sorun var. İstemci sunucusunun sunucu gibi değil de istemci gibi davranması durumunda bu iyidir; yani bağlantıları kabul etmek yerine başlatır. Ama bizim için durum tam tersi olacak. Bu durumda, hedef NAT yapmamız gerekir ki, trafik alırken kontrol düğümü bu trafiğin A istemcisinin sanal makinesi A'ya yönelik olduğunu anlasın, bu da harici bir adresten, örneğin 100.1.1.1'den NAT çevirisi yapmamız gerektiği anlamına gelir. .10.0.0.1, dahili adres 100'e. Bu durumda tüm istemciler aynı ağı kullanacak olsa da iç izolasyon tamamen korunur. Yani kontrol düğümünde dNAT ve sNAT yapmamız gerekiyor. Değişken adreslerle tek bir ağ mı yoksa harici ağlar mı yoksa her ikisini de aynı anda mı kullanacağınız, buluta ne getirmek istediğinize bağlıdır. Diyagrama kayan adresler eklemeyeceğiz, ancak daha önce eklenmiş olan harici ağları bırakacağız - her istemcinin kendi harici ağı vardır (şemada bunlar harici arayüzde vlan 200 ve XNUMX olarak belirtilmiştir).
Sonuç olarak, belli bir esnekliğe sahip ancak henüz hata tolerans mekanizmalarına sahip olmayan, ilginç ve aynı zamanda iyi düşünülmüş bir çözüm elde ettik.
İlk olarak, yalnızca bir kontrol düğümümüz var - onun başarısızlığı tüm sistemlerin çökmesine yol açacaktır. Bu sorunu çözmek için en az 3 düğümden oluşan bir çoğunluk oluşturmanız gerekir. Bunu şemaya ekleyelim:
Doğal olarak tüm düğümler senkronize edilir ve aktif bir düğüm ayrıldığında, başka bir düğüm onun sorumluluklarını devralır.
Bir sonraki sorun sanal makine diskleridir. Şu anda hipervizörlerin kendilerinde depolanıyorlar ve hipervizörde sorun olması durumunda tüm verileri kaybediyoruz - ve diski değil sunucunun tamamını kaybedersek bir baskının varlığı burada yardımcı olmayacaktır. Bunu yapabilmek için bir çeşit depolama için ön uç görevi görecek bir servis yapmamız gerekiyor. Ne tür bir depolama olacağı bizim için özellikle önemli değil, ancak verilerimizi hem diskin hem de düğümün ve muhtemelen tüm kabinin arızalanmasına karşı korumalıdır. Burada birkaç seçenek var - elbette Fiber Kanallı SAN ağları var, ancak dürüst olalım - FC zaten geçmişin bir kalıntısı - ulaşımda E1'in bir benzeri - evet, katılıyorum, hala kullanılıyor, ancak yalnızca onsuz kesinlikle imkansız olduğu yerde. Bu nedenle, daha ilginç alternatiflerin olduğunu bildiğim için 2020'de gönüllü olarak bir FC ağı kurmayacağım. Her ne kadar her biri kendine ait olsa da, FC'nin tüm sınırlamalarına rağmen ihtiyacımız olan tek şey olduğuna inananlar olabilir - tartışmayacağım, herkesin kendi fikri var. Ancak bana göre en ilginç çözüm Ceph gibi bir SDS kullanmaktır.
Ceph, eşlik kontrolüne sahip kodlardan (raid 5 veya 6'ya benzer) başlayarak, disklerin konumunu dikkate alarak farklı disklere tam veri çoğaltmayla biten bir dizi olası yedekleme seçeneğiyle yüksek düzeyde kullanılabilir bir veri depolama çözümü oluşturmanıza olanak tanır. sunucular ve dolaplardaki sunucular vb.
Ceph'i oluşturmak için 3 düğüme daha ihtiyacınız var. Depolamayla etkileşim de ağ üzerinden blok, nesne ve dosya depolama hizmetleri kullanılarak gerçekleştirilecek. Şemaya depolama ekleyelim:
Not: Ayrıca hiper yakınsanmış hesaplama düğümleri de oluşturabilirsiniz - bu, ceph depolama için özel düğümler ayırmadan, çeşitli işlevleri tek bir düğümde (örneğin, depolama+bilgi işlem) birleştirme kavramıdır. Aynı hataya dayanıklı şemayı elde edeceğiz - çünkü SDS, belirttiğimiz rezervasyon düzeyiyle verileri rezerve edecektir. Bununla birlikte, hiper yakınsak düğümler her zaman bir uzlaşmadır - depolama düğümü ilk bakışta göründüğü gibi yalnızca havayı ısıtmakla kalmaz (çünkü üzerinde sanal makine yoktur) - CPU kaynaklarını SDS'ye hizmet vermek için harcar (aslında her şeyi yapar) düğümlerin, disklerin vb. arızalarından sonra çoğaltma ve kurtarma). Yani, depolamayla birleştirirseniz hesaplama düğümünün gücünün bir kısmını kaybedersiniz.
Tüm bunların bir şekilde yönetilmesi gerekiyor; aracılığıyla bir makine, ağ, sanal yönlendirici vb. oluşturabileceğimiz bir şeye ihtiyacımız var. Bunu yapmak için, kontrol düğümüne gösterge panosu görevi görecek bir hizmet ekleyeceğiz - istemci bu portala http/ https aracılığıyla bağlanabilecek ve ihtiyaç duyduğu her şeyi (neredeyse neredeyse) yapabilecektir.
Sonuç olarak artık hataya dayanıklı bir sistemimiz var. Bu altyapının tüm unsurlarının bir şekilde yönetilmesi gerekiyor. Openstack'ın her biri belirli bir işlev sağlayan bir dizi proje olduğu daha önce açıklanmıştı. Gördüğümüz gibi yapılandırılması ve kontrol edilmesi gereken fazlasıyla unsur var. Bugün ağ kısmından bahsedeceğiz.
Nötron mimarisi
OpenStack'te, sanal makine bağlantı noktalarını ortak bir L2 ağına bağlamak, farklı L2 ağlarında bulunan VM'ler arasında trafik yönlendirmesinin yanı sıra dışarıya yönlendirmeyi sağlamak, NAT, Kayan IP, DHCP vb. hizmetleri sağlamaktan sorumlu olan Neutron'dur.
Yüksek düzeyde, ağ hizmetinin (temel kısım) işleyişi şu şekilde açıklanabilir.
VM'yi başlatırken ağ hizmeti:
- Belirli bir VM (veya bağlantı noktaları) için bir bağlantı noktası oluşturur ve DHCP hizmetine bu konuda bilgi verir;
- Yeni bir sanal ağ cihazı oluşturulur (libvirt aracılığıyla);
- VM, 1. adımda oluşturulan bağlantı noktalarına bağlanır;
İşin garibi, Neutron'un çalışması, Linux'a dalmış herkesin aşina olduğu standart mekanizmalara dayanıyor - ad alanları, iptables, linux köprüleri, openvswitch, conntrack vb.
Neutron'un bir SDN denetleyicisi olmadığı hemen açıklığa kavuşturulmalıdır.
Nötron birbirine bağlı birkaç bileşenden oluşur:
Openstack-nötron-sunucusu API aracılığıyla kullanıcı istekleriyle çalışan bir arka plan programıdır. Bu iblis herhangi bir ağ bağlantısının kaydedilmesiyle ilgilenmez, ancak bunun için gerekli bilgileri eklentilerine sağlar ve bunlar daha sonra istenen ağ öğesini yapılandırır. OpenStack düğümlerindeki Neutron aracıları Neutron sunucusuna kaydolur.
Neutron-server aslında python ile yazılmış ve iki bölümden oluşan bir uygulamadır:
- DİNLENME hizmeti
- Neutron Eklentisi (çekirdek/hizmet)
REST hizmeti, diğer bileşenlerden API çağrıları (örneğin, bazı bilgilerin sağlanmasına yönelik istek vb.) almak üzere tasarlanmıştır.
Eklentiler, API istekleri sırasında çağrılan, yani bir hizmetin ilişkilendirilmesi onlar aracılığıyla gerçekleşen eklenti yazılım bileşenleri/modülleridir. Eklentiler iki türe ayrılır - servis ve kök. Kural olarak, Horse eklentisi esas olarak VM'ler arasındaki adres alanını ve L2 bağlantılarını yönetmekten sorumludur ve hizmet eklentileri zaten VPN veya FW gibi ek işlevler sağlar.
Bugün mevcut olan eklentilerin listesi örneğin görüntülenebilir
Birkaç hizmet eklentisi olabilir, ancak yalnızca bir at eklentisi olabilir.
openstack-nötron-ml2 standart Openstack kök eklentisidir. Bu eklenti modüler bir mimariye sahiptir (önceki modelden farklı olarak) ve ağ hizmetini kendisine bağlı sürücüler aracılığıyla yapılandırır. Eklentinin kendisine biraz sonra bakacağız çünkü aslında OpenStack'in ağ kısmında sahip olduğu esnekliği sağlıyor. Kök eklenti değiştirilebilir (örneğin, Contrail Networking böyle bir değiştirme yapar).
RPC hizmeti (rabbitmq sunucusu) — kuyruk yönetimi ve diğer OpenStack hizmetleriyle etkileşimin yanı sıra ağ hizmeti aracıları arasındaki etkileşimi sağlayan bir hizmet.
Ağ aracıları — her düğümde bulunan ve ağ hizmetlerinin yapılandırıldığı aracılar.
Birkaç çeşit ajan vardır.
Ana ajan L2 ajanı. Bu aracılar, kontrol düğümleri de dahil olmak üzere (daha doğrusu, kiracılar için herhangi bir hizmet sağlayan tüm düğümlerde) hipervizörlerin her birinde çalışır ve ana işlevleri, sanal makineleri ortak bir L2 ağına bağlamak ve ayrıca herhangi bir olay meydana geldiğinde uyarı oluşturmaktır ( örneğin bağlantı noktasını devre dışı bırakın/etkinleştirin).
Bir sonraki, daha az önemli olmayan ajan ise L3 ajanı. Varsayılan olarak, bu aracı yalnızca bir ağ düğümünde çalışır (çoğunlukla ağ düğümü bir kontrol düğümüyle birleştirilir) ve kiracı ağları arasında (hem kendi ağları hem de diğer kiracıların ağları arasında) yönlendirme sağlar ve dış dünya tarafından erişilebilir olup, NAT ve DHCP hizmeti). Bununla birlikte, bir DVR (dağıtılmış yönlendirici) kullanıldığında, hesaplama düğümlerinde bir L3 eklentisine olan ihtiyaç da ortaya çıkar.
L3 aracısı, her kiracıya kendi yalıtılmış ağ kümesini ve trafiği yönlendiren ve Katman 2 ağları için ağ geçidi hizmetleri sağlayan sanal yönlendiricilerin işlevselliğini sağlamak için Linux ad alanlarını kullanır.
veritabanı — ağların, alt ağların, bağlantı noktalarının, havuzların vb. tanımlayıcılarından oluşan bir veritabanı.
Aslında Neutron, herhangi bir ağ varlığının oluşturulmasından gelen API isteklerini kabul eder, isteğin kimliğini doğrular ve RPC (bir eklentiye veya aracıya erişiyorsa) veya REST API (SDN'de iletişim kuruyorsa) aracılığıyla aracılara (eklentiler aracılığıyla) iletir. Talep edilen hizmeti organize etmek için gerekli talimatlar.
Şimdi test kurulumuna dönelim (nasıl dağıtıldığı ve neleri içerdiğini, daha sonra pratik kısımda göreceğiz) ve her bileşenin nerede bulunduğunu görelim:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Aslında Nötron'un tüm yapısı bu. Artık ML2 eklentisine biraz zaman ayırmaya değer.
Modüler Katman 2
Yukarıda da bahsettiğimiz gibi eklenti standart bir OpenStack root eklentisidir ve modüler bir mimariye sahiptir.
ML2 eklentisinin öncülü, örneğin tek bir kurulumda birkaç teknolojinin bir karışımının kullanılmasına izin vermeyen monolitik bir yapıya sahipti. Örneğin, hem openvswitch'i hem de linuxbridge'i aynı anda kullanamazsınız - ne birinciyi ne de ikinciyi. Bu nedenle mimarisiyle ML2 eklentisi oluşturuldu.
ML2'nin iki bileşeni vardır - iki tür sürücü: Tip sürücüleri ve Mekanizma sürücüleri.
Sürücüleri yazın Ağ bağlantılarını düzenlemek için kullanılacak teknolojileri (örneğin VxLAN, VLAN, GRE) belirleyin. Sürücü aynı zamanda farklı teknolojilerin kullanımına da olanak tanıyor. Standart teknoloji, yer paylaşımlı ağlar ve vlan harici ağlar için VxLAN kapsüllemedir.
Tip sürücüleri aşağıdaki ağ türlerini içerir:
Düz - etiketlemeden ağ
VLAN - etiketli ağ
Yerel — hepsi bir arada kurulumlar için özel bir ağ türü (bu tür kurulumlar geliştiriciler veya eğitim için gereklidir)
GRE — GRE tünellerini kullanan yer paylaşımlı ağ
VxLAN — VxLAN tünellerini kullanan yer paylaşımlı ağ
Mekanizma sürücüleri sürücü türünde belirtilen teknolojilerin organizasyonunu sağlayan araçları tanımlar (örneğin, openvswitch, sr-iov, opendaylight, OVN vb.).
Bu sürücünün uygulanmasına bağlı olarak ya Neutron tarafından kontrol edilen aracılar kullanılacak ya da L2 ağlarının düzenlenmesi, yönlendirme vb. ile ilgili tüm sorunları halleden harici bir SDN denetleyicisine bağlantılar kullanılacaktır.
Örnek: ML2'yi OVS ile birlikte kullanırsak, OVS'yi yöneten her bilgi işlem düğümüne bir L2 aracısı yüklenir. Bununla birlikte, örneğin OVN veya OpenDayLight kullanırsak, OVS'nin kontrolü onların yetki alanına girer - Neutron, kök eklenti aracılığıyla denetleyiciye komutlar verir ve zaten kendisine söyleneni yapar.
Open vSwitch'i tazeleyelim
Şu anda OpenStack'in temel bileşenlerinden biri Open vSwitch'tir.
OpenStack'i Juniper Contrail veya Nokia Nuage gibi herhangi bir ek satıcı SDN'si olmadan kurduğunuzda, OVS bulut ağının ana ağ bileşenidir ve iptables, conntrack, ad alanlarıyla birlikte tam teşekküllü çok kiracılı yer paylaşımlı ağları düzenlemenize olanak tanır. Doğal olarak, bu bileşen, örneğin üçüncü taraf tescilli (satıcı) SDN çözümleri kullanıldığında değiştirilebilir.
OVS, sanallaştırılmış ortamlarda sanal trafik ileticisi olarak kullanılmak üzere tasarlanmış açık kaynaklı bir yazılım anahtarıdır.
Şu anda OVS, QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK vb. teknolojileri içeren çok iyi bir işlevselliğe sahiptir.
Not: OVS başlangıçta yüksek yüklü telekomünikasyon işlevleri için bir yazılım anahtarı olarak tasarlanmamıştı ve daha çok WEB sunucusu veya posta sunucusu gibi daha az bant genişliği gerektiren BT işlevleri için tasarlandı. Bununla birlikte, OVS daha da geliştirilmektedir ve OVS'nin mevcut uygulamaları performansını ve yeteneklerini büyük ölçüde geliştirmiştir, bu da telekom operatörleri tarafından yüksek yüklü işlevlerle kullanılmasına olanak sağlamaktadır; örneğin, DPDK hızlandırma desteğine sahip bir OVS uygulaması bulunmaktadır.
OVS'nin bilmeniz gereken üç önemli bileşeni vardır:
- Çekirdek modülü - çekirdek alanında yer alan ve trafiği kontrol elemanından alınan kurallara göre işleyen bir bileşen;
- vAnahtarı arka plan programı (ovs-vswitchd), çekirdek modülünün programlanmasından sorumlu olan, kullanıcı alanında başlatılan bir işlemdir - yani doğrudan anahtarın çalışma mantığını temsil eder
- Veritabanı sunucusu - OVS çalıştıran her ana bilgisayarda bulunan ve yapılandırmanın saklandığı yerel bir veritabanı. SDN denetleyicileri, OVSDB protokolünü kullanarak bu modül aracılığıyla iletişim kurabilir.
Tüm bunlara ovs-vsctl, ovs-appctl, ovs-ofctl, vb. gibi bir dizi teşhis ve yönetim yardımcı programı eşlik eder.
Şu anda Openstack, telekom operatörleri tarafından EPC, SBC, HLR vb. gibi ağ işlevlerini kendisine taşımak için yaygın olarak kullanılmaktadır. Bazı işlevler OVS ile olduğu gibi sorunsuzca yaşayabilir, ancak örneğin EPC abone trafiğini işler - sonra geçer çok büyük miktarda trafik (artık trafik hacimleri saniyede birkaç yüz gigabite ulaşıyor). Doğal olarak, bu tür trafiği çekirdek alanı üzerinden yönlendirmek (iletici varsayılan olarak orada bulunduğundan) en iyi fikir değildir. Bu nedenle OVS, trafiği NIC'den kullanıcı alanına çekirdeği atlayarak iletmek için DPDK hızlandırma teknolojisini kullanarak genellikle tamamen kullanıcı alanına dağıtılır.
Not: Telekom işlevleri için dağıtılan bir bulut için, OVS'yi atlayarak bir bilgi işlem düğümünden gelen trafiği doğrudan anahtarlama ekipmanına çıkarmak mümkündür. Bu amaçla SR-IOV ve Passthrough mekanizmaları kullanılmaktadır.
Bu gerçek bir düzende nasıl çalışır?
Şimdi pratik kısma geçelim ve her şeyin pratikte nasıl çalıştığını görelim.
Öncelikle basit bir Openstack kurulumunu dağıtalım. Elimde deneyler için bir dizi sunucu bulunmadığından, prototipi sanal makinelerden tek bir fiziksel sunucuda birleştireceğiz. Evet, doğal olarak böyle bir çözüm ticari amaçlara uygun değil ancak Openstack'ta ağın nasıl çalıştığına dair bir örnek görmek için böyle bir kurulum gözler için yeterli. Dahası, böyle bir kurulum eğitim amaçlı olarak daha da ilginçtir - çünkü trafiği vb. yakalayabilirsiniz.
Sadece temel kısmı görmemiz gerektiğinden, birden fazla ağ kullanamıyoruz ve her şeyi yalnızca iki ağ kullanarak yükseltiyoruz ve bu düzendeki ikinci ağ, yalnızca bulut altı ve DNS sunucusuna erişim için kullanılacak. Şimdilik dış ağlara değinmeyeceğiz - bu ayrı bir büyük makalenin konusu.
O halde sırayla başlayalım. İlk önce küçük bir teori. Openstack'ı TripleO (Openstack üzerinde Openstack) kullanarak kuracağız. TripleO'nun özü, Openstack'ı hepsi bir arada (yani, tek bir düğümde) alt bulut olarak kurmamız ve ardından, overcloud adı verilen operasyon için tasarlanan Openstack'ı kurmak için konuşlandırılmış Openstack'ın yeteneklerini kullanmamızdır. Undercloud, fiziksel sunucuları (çıplak donanım) (Ironic projesi) yönetme konusundaki doğal yeteneğini, bilgi işlem, kontrol ve depolama düğümleri rollerini yerine getirecek hipervizörleri sağlamak için kullanacak. Yani, Openstack'ı dağıtmak için herhangi bir üçüncü taraf araç kullanmıyoruz; Openstack'ı Openstack kullanarak dağıtıyoruz. Kurulum ilerledikçe daha da netleşecek, o yüzden burada durup ilerlemeyeceğiz.
Not: Bu makalede basitlik adına dahili Openstack ağları için ağ izolasyonu kullanmadım, ancak her şey yalnızca tek bir ağ kullanılarak dağıtılıyor. Bununla birlikte, ağ izolasyonunun varlığı veya yokluğu, çözümün temel işlevselliğini etkilemez; her şey izolasyon kullanıldığında olduğu gibi tamamen aynı şekilde çalışacaktır, ancak trafik aynı ağ üzerinden akacaktır. Ticari bir kurulum için doğal olarak farklı vlanlar ve arayüzler kullanılarak izolasyon kullanılması gerekmektedir. Örneğin ceph depolama yönetimi trafiği ve veri trafiğinin kendisi (disklere makine erişimi vb.) izole edildiğinde farklı alt ağlar kullanır (Depolama yönetimi ve Depolama) ve bu, örneğin bu trafiği bölerek çözümü hataya daha dayanıklı hale getirmenize olanak tanır. , farklı bağlantı noktaları arasında veya farklı trafik için farklı QoS profilleri kullanarak, veri trafiğinin sinyal trafiğini sıkıştırmaması sağlanır. Bizim durumumuzda aynı ağ üzerinden gidecekler ve aslında bu bizi hiçbir şekilde sınırlamıyor.
Not: Sanal makineleri sanal makinelere dayalı bir sanal ortamda çalıştıracağımız için öncelikle iç içe sanallaştırmayı etkinleştirmemiz gerekiyor.
İç içe sanallaştırmanın etkin olup olmadığını şu şekilde kontrol edebilirsiniz:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#N harfini görüyorsanız ağda bulduğunuz herhangi bir kılavuza göre iç içe sanallaştırma desteğini etkinleştiriyoruz; örneğin .
Aşağıdaki devreyi sanal makinelerden kurmamız gerekiyor:
Benim durumumda, gelecekteki kurulumun bir parçası olan sanal makineleri bağlamak için (ve bunlardan 7 tanesini aldım, ancak çok fazla kaynağınız yoksa 4 tanesiyle de idare edebilirsiniz), OpenvSwitch'i kullandım. Bir ovs köprüsü oluşturdum ve sanal makineleri buna port grupları aracılığıyla bağladım. Bunu yapmak için şöyle bir xml dosyası oluşturdum:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Burada üç bağlantı noktası grubu belirtilmiştir - iki erişim ve bir hat (ikincisi DNS sunucusu için gerekliydi, ancak onsuz yapabilir veya ana makineye yükleyebilirsiniz - hangisi sizin için daha uygunsa). Daha sonra, bu şablonu kullanarak virsh net-define aracılığıyla kendimizinkini ilan ediyoruz:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Şimdi hiper yönetici bağlantı noktası yapılandırmalarını düzenliyoruz:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Not: Bu senaryoda, ovs-br1 bağlantı noktasındaki adrese vlan etiketi olmadığı için erişilmeyecektir. Bunu düzeltmek için sudo ovs-vsctl set port ovs-br1 tag=100 komutunu vermeniz gerekir. Ancak, yeniden başlatmanın ardından bu etiket kaybolacaktır (eğer biri onun yerinde kalmasını nasıl sağlayacağını biliyorsa, çok minnettar olacağım). Ancak bu o kadar önemli değil çünkü bu adrese yalnızca kurulum sırasında ihtiyacımız olacak ve Openstack tamamen konuşlandırıldığında buna ihtiyacımız olmayacak.
Daha sonra bir bulut altı makinesi oluşturuyoruz:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Kurulum sırasında makine adı, şifreler, kullanıcılar, ntp sunucuları vb. Gibi gerekli tüm parametreleri ayarlarsınız, bağlantı noktalarını hemen yapılandırabilirsiniz, ancak kişisel olarak benim için kurulumdan sonra makinede oturum açmak daha kolaydır. Konsolu açın ve gerekli dosyaları düzeltin. Zaten hazır bir görüntünüz varsa, onu kullanabilir veya benim yaptığımı yapabilirsiniz; minimum Centos 7 görüntüsünü indirin ve VM'yi yüklemek için onu kullanın.
Başarılı kurulumun ardından, undercloud kurulumu yapabileceğiniz bir sanal makineye sahip olmalısınız.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningÖncelikle kurulum işlemi için gerekli araçları kurun:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Bulut altı kurulumu
Bir yığın kullanıcısı oluşturuyoruz, bir şifre belirliyoruz, bunu sudoer'a ekliyoruz ve ona, şifre girmeye gerek kalmadan sudo aracılığıyla root komutlarını yürütme yeteneği veriyoruz:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackŞimdi hosts dosyasında tam bulut altı adını belirtiyoruz:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Daha sonra depoları ekliyoruz ve ihtiyacımız olan yazılımı yüklüyoruz:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleNot: Ceph'i yüklemeyi planlamıyorsanız, ceph ile ilgili komutları girmenize gerek yoktur. Ben Queens sürümünü kullandım ama siz dilediğinizi kullanabilirsiniz.
Ardından, bulut altı yapılandırma dosyasını kullanıcının ana dizin yığınına kopyalayın:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confŞimdi bu dosyayı kurulumumuza göre ayarlayarak düzeltmemiz gerekiyor.
Bu satırları dosyanın başına eklemeniz gerekir:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10O halde ayarlara geçelim:
undercloud_hostname — Bulut altı sunucusunun tam adı, DNS sunucusundaki girişle eşleşmelidir
yerel_ip — ağ provizyonuna yönelik yerel bulut altı adresi
ağ_geçidi — Overcloud düğümlerinin kurulumu sırasında dış dünyaya erişim için ağ geçidi görevi görecek olan aynı yerel adres aynı zamanda yerel IP ile de çakışıyor
undercloud_public_host — harici API adresi, temel hazırlık ağındaki herhangi bir ücretsiz adres atanır
undercloud_admin_host dahili API adresi, temel hazırlık ağındaki herhangi bir ücretsiz adres atanır
undercloud_nameservers - Dns sunucusu
created_service_certificate - mevcut örnekte bu satır çok önemlidir, çünkü false olarak ayarlamazsanız kurulum sırasında bir hata alırsınız, sorun Red Hat hata takip cihazında anlatılmıştır.
yerel_arayüz ağ provizyonunda arayüz. Bu arayüz, bulut altı dağıtımı sırasında yeniden yapılandırılacağından, bulut altı üzerinde iki arayüze sahip olmanız gerekir; biri erişim için, ikincisi ise temel hazırlığı yapmak için
local_mtu — MTU. Bir test laboratuvarımız olduğundan ve OVS switch portlarında MTU'm 1500 olduğundan, VxLAN'da kapsüllenen paketlerin geçebilmesi için bunu 1450'ye ayarlamak gerekiyor.
ağ_cidr — temel hazırlık ağı
maskeli balo — harici bir ağa erişmek için NAT kullanma
maskeli balo ağı - NAT'lanacak ağ
dhcp_start — Bulut üzerinde dağıtım sırasında adreslerin düğümlere atanacağı adres havuzunun başlangıç adresi
dhcp_end — Bulut üzerinde dağıtım sırasında adreslerin düğümlere atanacağı adres havuzunun son adresi
muayene_iprange — iç gözlem için gerekli olan adreslerden oluşan bir havuz (yukarıdaki havuzla örtüşmemelidir)
Scheduler_max_attempts — bulutu kurmaya yönelik maksimum deneme sayısı (düğüm sayısından büyük veya ona eşit olmalıdır)
Dosya açıklandıktan sonra, bulut altı dağıtımı için komutu verebilirsiniz:
openstack undercloud install
İşlem ütünüze bağlı olarak 10 ile 30 dakika arasında sürer. Sonuçta şu şekilde çıktı görmelisiniz:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Bu çıktı, undercloud'u başarıyla kurduğunuzu ve artık undercloud'un durumunu kontrol edip overcloud'u kurmaya devam edebileceğinizi söylüyor.
ifconfig çıktısına bakarsanız yeni bir köprü arayüzünün ortaya çıktığını göreceksiniz
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud dağıtımı artık bu arayüz üzerinden gerçekleştirilecek.
Aşağıdaki çıktıdan tüm hizmetlerin tek bir düğümde bulunduğunu görebilirsiniz:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Bulut altı ağ kısmının yapılandırması aşağıdadır:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Bulut kurulumu
Şu anda yalnızca alt bulutumuz var ve üst bulutun birleştirileceği yeterli sayıda düğümümüz yok. Bu nedenle öncelikle ihtiyacımız olan sanal makineleri dağıtalım. Dağıtım sırasında, alt bulutun kendisi işletim sistemini ve gerekli yazılımı üst bulut makinesine yükleyecektir - yani, makineyi tamamen dağıtmamıza gerek yoktur, yalnızca onun için bir disk (veya diskler) oluşturup parametrelerini belirlememiz gerekir - yani Aslında, üzerinde işletim sistemi kurulu olmayan çıplak bir sunucuya sahip oluyoruz.
Sanal makinelerimizin disklerinin bulunduğu klasöre gidelim ve gerekli boyutta diskler oluşturalım:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GRoot olarak çalıştığımız için haklarda sorun yaşamamak için bu disklerin sahibini değiştirmemiz gerekiyor:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Not: Ceph'i incelemek için kurmayı planlamıyorsanız, komutlar en az iki diskli en az 3 düğüm oluşturmaz, ancak şablonda vda, vdb vb. sanal disklerin kullanılacağını belirtir.
Harika, şimdi tüm bu makineleri tanımlamamız gerekiyor:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Sonunda, /tmp/ klasöründeki her makinenin açıklamasını içeren bir xml dosyası oluşturan -print-xml > /tmp/storage-1.xml komutu vardır; eğer eklemezseniz, sanal makineleri tanımlayabilir.
Şimdi tüm bu makineleri virsh'te tanımlamamız gerekiyor:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Şimdi küçük bir nüans - tripleO, kurulum ve iç gözlem sırasında sunucuları yönetmek için IPMI'yı kullanıyor.
İç gözlem, düğümlerin daha fazla sağlanması için gerekli parametrelerini elde etmek amacıyla donanımı inceleme sürecidir. İç gözlem, yalın donanım sunucularla çalışmak üzere tasarlanmış bir hizmet olan ironik kullanılarak gerçekleştirilir.
Ancak sorun şu: donanım IPMI sunucularının ayrı bir bağlantı noktası (veya paylaşılan bir bağlantı noktası var, ancak bu önemli değil) olmasına rağmen, sanal makinelerde bu tür bağlantı noktaları yoktur. Burada yardımımıza vbmc adı verilen bir koltuk değneği geliyor; bu, bir IPMI bağlantı noktasını taklit etmenize olanak tanıyan bir yardımcı programdır. Bu nüans, özellikle bir ESXI hipervizöründe böyle bir laboratuvar kurmak isteyenler için dikkat etmeye değer - dürüst olmak gerekirse, vbmc'nin bir analogu olup olmadığını bilmiyorum, bu yüzden her şeyi dağıtmadan önce bu konuyu merak etmeye değer. .
vbmc'yi yükleyin:
yum install yum install python2-virtualbmcİşletim sisteminiz paketi bulamıyorsa depoyu ekleyin:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmŞimdi yardımcı programı kurduk. Burada her şey utanç verici derecede sıradan. Artık vbmc listesinde hiçbir sunucunun olmaması mantıklı
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Görünebilmeleri için manuel olarak şu şekilde bildirilmeleri gerekir:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Komut sözdiziminin açıklama olmadan açık olduğunu düşünüyorum. Ancak şimdilik tüm oturumlarımız DOWN durumundadır. UP durumuna geçmeleri için bunları etkinleştirmeniz gerekir:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Ve son dokunuş - güvenlik duvarı kurallarını düzeltmeniz (veya tamamen devre dışı bırakmanız) gerekir:
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Şimdi bulut altına gidelim ve her şeyin çalışıp çalışmadığını kontrol edelim. Ana makinenin adresi 192.168.255.200, dağıtıma hazırlık sırasında gerekli ipmitool paketini undercloud'a ekledik:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningGördüğünüz gibi vbmc üzerinden kontrol düğümünü başarıyla başlattık. Şimdi kapatıp devam edelim:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Bir sonraki adım, overcloud'un kurulacağı düğümlerin iç gözlemidir. Bunu yapmak için düğümlerimizin açıklamasını içeren bir json dosyası hazırlamamız gerekiyor. Çıplak sunuculara kurulumun aksine, dosyanın her makine için vbmc'nin çalıştığı bağlantı noktasını gösterdiğini lütfen unutmayın.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Not: Kontrol düğümünün iki arayüzü vardır ancak bu durumda bu önemli değil, bu kurulumda bizim için bir tane yeterli olacaktır.
Şimdi json dosyasını hazırlıyoruz. Temel hazırlığın gerçekleştirileceği bağlantı noktasının haşhaş adresini, düğümlerin parametrelerini belirtmemiz, onlara ad vermemiz ve ipmi'ye nasıl ulaşacağımızı belirtmemiz gerekiyor:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Artık ironik görseller hazırlamamız gerekiyor. Bunu yapmak için bunları wget aracılığıyla indirin ve yükleyin:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Görüntüleri bulut altına yükleme:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Tüm resimlerin yüklendiğini kontrol etme
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Bir şey daha var; bir DNS sunucusu eklemeniz gerekiyor:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Artık iç gözlem için şu komutu verebiliriz:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Çıktıdan da görebileceğiniz gibi her şey hatasız tamamlandı. Tüm düğümlerin kullanılabilir durumda olup olmadığını kontrol edelim:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Düğümler farklı bir durumdaysa, genellikle yönetilebilirse, bir şeyler ters gitti demektir ve günlüğe bakıp bunun neden olduğunu anlamanız gerekir. Bu senaryoda sanallaştırma kullandığımızı ve sanal makinelerin veya vbmc'nin kullanımıyla ilgili hatalar olabileceğini unutmayın.
Daha sonra, hangi düğümün hangi işlevi gerçekleştireceğini, yani düğümün konuşlandırılacağı profili belirtmemiz gerekir:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Her düğüm için profili belirtin:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Her şeyi doğru yaptığımızı kontrol edelim:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Her şey doğruysa, overcloud'u dağıtma komutunu veriyoruz:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuGerçek bir kurulumda, özelleştirilmiş şablonlar doğal olarak kullanılacaktır; bizim durumumuzda, şablondaki her düzenlemenin açıklanması gerekeceğinden bu, süreci büyük ölçüde karmaşıklaştıracaktır. Daha önce de yazdığımız gibi basit bir kurulum bile nasıl çalıştığını görmemiz için yeterli olacaktır.
Not: --libvirt-type qemu değişkeni bu durumda gereklidir çünkü iç içe sanallaştırmayı kullanacağız. Aksi takdirde sanal makineleri çalıştıramazsınız.
Şimdi yaklaşık bir saatiniz veya belki daha fazla süreniz var (donanımın özelliklerine bağlı olarak) ve bu sürenin sonunda aşağıdaki mesajı göreceğinizi umabilirsiniz:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Artık üzerinde çalışabileceğiniz, deneyler yapabileceğiniz vb. neredeyse tam teşekküllü bir openstack sürümüne sahipsiniz.
Her şeyin düzgün çalışıp çalışmadığını kontrol edelim. Kullanıcının ana dizin yığınında iki dosya vardır - biri stackrc (bulut altı yönetimi için) ve ikincisi overcloudrc (overcloud yönetimi için). Bu dosyalar, kimlik doğrulama için gerekli bilgileri içerdikleri için kaynak olarak belirtilmelidir.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Kurulumum hala küçük bir dokunuş gerektiriyor; birlikte çalıştığım makine farklı bir ağda olduğundan denetleyiciye bir rota eklemek. Bunu yapmak için ısı yöneticisi hesabı altında kontrol-1'e gidin ve rotayı kaydedin
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Artık ufka gidebilirsiniz. Tüm bilgiler - adresler, kullanıcı adı ve şifre - /home/stack/overcloudrc dosyasındadır. Son diyagram şuna benzer:
Bu arada kurulumumuzda makine adresleri DHCP üzerinden veriliyordu ve gördüğünüz gibi “rastgele” veriliyor. İhtiyacınız olursa, dağıtım sırasında hangi adresin hangi makineye eklenmesi gerektiğini şablonda kesin olarak tanımlayabilirsiniz.
Sanal makineler arasında trafik nasıl akıyor?
Bu yazıda trafiği geçmek için üç seçeneğe bakacağız
- Bir L2 ağında bir hipervizörde iki makine
- Aynı L2 ağında farklı hipervizörlerdeki iki makine
- Farklı ağlardaki iki makine (ağlar arası köklendirme)
Dış dünyaya harici bir ağ aracılığıyla erişimi olan, değişken adresler ve dağıtılmış yönlendirme kullanan durumları bir dahaki sefere ele alacağız, şimdilik iç trafiğe odaklanacağız.
Kontrol etmek için aşağıdaki diyagramı bir araya getirelim:
4 sanal makine oluşturduk - 3 tanesi bir L2 ağında - net-1 ve 1 tane daha net-2 ağında
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Oluşturulan makinelerin hangi hipervizörlerde bulunduğunu görelim:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(bulut) [stack@undercloud ~]$
VM-1 ve vm-3 makineleri hesaplama-0'da, vm-2 ve vm-4 makineleri ise hesaplama-1 düğümünde bulunur.
Ayrıca, belirtilen ağlar arasında yönlendirmeyi etkinleştirmek için bir sanal yönlendirici oluşturulmuştur:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Yönlendiricinin, ağlar için ağ geçidi görevi gören iki sanal bağlantı noktası vardır:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Ancak trafiğin nasıl aktığına bakmadan önce, kontrol düğümünde (aynı zamanda bir ağ düğümüdür) ve hesaplama düğümünde şu anda sahip olduğumuz şeylere bakalım. Hesaplama düğümüyle başlayalım.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Şu anda düğümün üç ovs köprüsü var - br-int, br-tun, br-ex. Gördüğümüz gibi aralarında bir dizi arayüz var. Anlama kolaylığı için tüm bu arayüzleri şema üzerinde çizelim ve ne olacağını görelim.
VxLAN tünellerinin yükseltildiği adreslere bakıldığında, bir tünelin hesaplama-1'e (192.168.255.26) yükseltildiği, ikinci tünelin ise kontrol-1'e (192.168.255.15) baktığı görülmektedir. Ancak en ilginç şey, br-ex'in fiziksel arayüzlerinin olmaması ve hangi akışların yapılandırıldığına bakarsanız, bu köprünün şu anda yalnızca trafiği azaltabildiğini görebilirsiniz.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Çıktıdan da görebileceğiniz gibi adres sanal köprü arayüzüne değil doğrudan fiziksel porta vidalanmıştır.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
İlk kurala göre phy-br-ex limanından gelen her şey atılmalıdır.
Aslında şu anda trafiğin bu arayüz (br-int ile arayüz) dışında bu köprüye gelebileceği başka hiçbir yer yok ve düşüşlere bakılırsa BUM trafiği zaten köprüye akmış durumda.
Yani, trafik bu düğümden yalnızca VxLAN tüneli üzerinden çıkabilir, başka hiçbir şey olamaz. Ancak DVR'ı açarsanız durum değişecektir, ancak bununla başka zaman ilgileniriz. Ağ izolasyonunu kullanırken, örneğin vlan'ları kullanırken, vlan 3'da bir L0 arayüzüne değil, birkaç arayüze sahip olacaksınız. Bununla birlikte, VxLAN trafiği de düğümden aynı şekilde ayrılacak ancak aynı zamanda bir tür özel vlan içinde kapsüllenecektir.
Hesaplama düğümünü çözdük, şimdi kontrol düğümüne geçelim.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Aslında her şeyin aynı olduğunu söyleyebiliriz ancak IP adresi artık fiziksel arayüzde değil sanal köprüdedir. Bunun yapılmasının nedeni, bu limanın trafiğin dış dünyaya çıkacağı liman olmasıdır.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Bu bağlantı noktası br-ex köprüsüne bağlıdır ve üzerinde vlan etiketi olmadığından, bu bağlantı noktası tüm vlan'lara izin verilen bir ana bağlantı noktasıdır, artık trafik, vlan-id 0 ile belirtildiği gibi etiket olmadan dışarı çıkıyor. yukarıdaki çıktı.
Şu anda diğer her şey hesaplama düğümüne benziyor; aynı köprüler, iki hesaplama düğümüne giden aynı tüneller.
Bu yazımızda depolama düğümlerini ele almayacağız ancak anlamak için bu düğümlerin ağ kısmının rezalet derecede sıradan olduğunu söylemek gerekiyor. Bizim durumumuzda, kendisine IP adresi atanmış yalnızca bir fiziksel bağlantı noktası (eth0) vardır ve hepsi bu. VxLAN tüneli, tünel köprüleri vb. Yok - hiçbir anlamı olmadığı için hiç ov yok. Ağ yalıtımını kullanırken, bu düğümün iki arabirimi olacaktır (fiziksel bağlantı noktaları, gövde veya yalnızca iki vlan - önemli değil - ne istediğinize bağlıdır) - biri yönetim için, ikincisi trafik için (VM diskine yazma) , diskten okuma vb.)
Herhangi bir hizmetin yokluğunda düğümlerde nelere sahip olduğumuzu bulduk. Şimdi 4 sanal makine başlatalım ve yukarıda açıklanan şemanın nasıl değiştiğini görelim - bağlantı noktalarına, sanal yönlendiricilere vb. sahip olmalıyız.
Şu ana kadar ağımız şöyle görünüyor:
Her bilgisayar düğümünde iki sanal makinemiz var. Compute-0'ı örnek olarak kullanarak her şeyin nasıl dahil edildiğini görelim.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Makinenin yalnızca bir sanal arayüzü vardır - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Bu arayüz linux köprüsüne bakar:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Çıktıdan görebileceğiniz gibi köprüde yalnızca iki arayüz vardır - tap95d96a75-a0 ve qvb95d96a75-a0.
Burada OpenStack'teki sanal ağ cihazı türleri üzerinde biraz durmaya değer:
vtap - bir örneğe bağlı sanal arayüz (VM)
qbr - Linux köprüsü
qvb ve qvo - Linux köprüsüne ve Açık vSwitch köprüsüne bağlı vEth çifti
br-int, br-tun, br-vlan — vSwitch köprülerini açın
patch-, int-br-, phy-br- - Köprüleri bağlayan vSwitch yama arayüzlerini açın
qg, qr, ha, fg, sg - OVS'ye bağlanmak için sanal cihazlar tarafından kullanılan vSwitch bağlantı noktalarını açın
Anladığınız gibi, köprüde vEth çifti olan bir qvb95d96a75-a0 bağlantı noktamız varsa, o zaman bir yerlerde onun mantıksal olarak qvo95d96a75-a0 olarak adlandırılması gereken karşılığı vardır. OVS'de hangi bağlantı noktalarının bulunduğunu görelim.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Gördüğümüz gibi liman br-int'de. Br-int, sanal makine bağlantı noktalarını sonlandıran bir anahtar görevi görür. Çıkışta qvo95d96a75-a0'a ek olarak qvo5bd37136-47 bağlantı noktası da görünür. Bu, ikinci sanal makinenin bağlantı noktasıdır. Sonuç olarak diyagramımız şu şekilde görünüyor:
Dikkatli okuyucunun hemen ilgisini çekmesi gereken bir soru: sanal makine bağlantı noktası ile OVS bağlantı noktası arasındaki linux köprüsü nedir? Gerçek şu ki, makineyi korumak için iptables'tan başka bir şey olmayan güvenlik grupları kullanılıyor. OVS iptables ile çalışmadığından bu "koltuk değneği" icat edildi. Ancak, geçerliliğini yitiriyor; yeni sürümlerde yerini conntrack alıyor.
Yani, sonuçta şema şöyle görünür:
Bir L2 ağında bir hipervizörde iki makine
Bu iki VM aynı L2 ağında ve aynı hipervizörde bulunduğundan, her iki makine de aynı VLAN üzerinde olacağından aralarındaki trafik mantıksal olarak br-int üzerinden yerel olarak akacaktır:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Aynı L2 ağında farklı hipervizörlerdeki iki makine
Şimdi aynı L2 ağındaki ancak farklı hipervizörlerde bulunan iki makine arasındaki trafiğin nasıl ilerleyeceğini görelim. Dürüst olmak gerekirse pek bir şey değişmeyecek, sadece hipervizörler arasındaki trafik vxlan tünelinden geçecek. Bir örneğe bakalım.
Aralarındaki trafiği izleyeceğimiz sanal makinelerin adresleri:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Compute-0'da br-int'deki yönlendirme tablosuna bakıyoruz:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Trafik 2 numaralı bağlantı noktasına gitmelidir - bunun ne tür bir bağlantı noktası olduğunu görelim:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Bu patch-tun'dur, yani br-tun'daki arayüz. Bakalım br-tun'daki pakete ne olacak:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Paket VxLAN'da paketlenir ve bağlantı noktası 2'ye gönderilir. Bağlantı noktası 2'nin nereye gittiğini görelim:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Bu, hesaplama-1'deki bir vxlan tünelidir:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Hadi hesaplama-1'e gidelim ve pakette bundan sonra ne olacağını görelim:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac, hesaplama-1'deki br-int yönlendirme tablosundadır ve yukarıdaki çıktıdan görülebileceği gibi, br-tun'a giden bağlantı noktası olan bağlantı noktası 2 aracılığıyla görülebilir:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46O zaman hesaplama-1'deki br-int'de bir hedef poppy olduğunu görüyoruz:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Yani, alınan paket, arkasında zaten bir sanal makine örneği-3 bulunan bağlantı noktası 00000003'e uçacaktır.
Openstack'ı sanal altyapı üzerinde öğrenim için dağıtmanın güzelliği, hipervizörler arasındaki trafiği kolayca yakalayabilmemiz ve neler olduğunu görebilmemizdir. Şimdi yapacağımız şey bu, vnet bağlantı noktasında compute-0'a doğru tcpdump'ı çalıştırın:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************İlk satır, Patek'in 10.0.1.85 adresinden 10.0.1.88 adresine (ICMP trafiği) gittiğini ve vni 22 ile bir VxLAN paketine sarıldığını ve paketin 192.168.255.19 numaralı ana bilgisayardan (compute-0) 192.168.255.26 numaralı ana bilgisayara gittiğini gösteriyor. .1 ( hesaplama-XNUMX). VNI'nin ovs'da belirtilenle eşleşip eşleşmediğini kontrol edebiliriz.
Bu satıra geri dönelim actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16, onaltılık sayı sisteminde vni'dir. Bu sayıyı 16'uncu sisteme çevirelim:
16 = 6*16^0+1*16^1 = 6+16 = 22Yani vni gerçekliğe karşılık gelir.
İkinci satır dönüş trafiğini gösteriyor, yani bunu açıklamanın bir anlamı yok, orada her şey açık.
Farklı ağlardaki iki makine (ağlar arası yönlendirme)
Bugün için son durum, sanal bir yönlendirici kullanarak bir proje içindeki ağlar arasında yönlendirme yapmaktır. DVR'sız bir durum düşünüyoruz (buna başka bir makalede bakacağız), bu nedenle yönlendirme ağ düğümünde gerçekleşir. Bizim durumumuzda ağ düğümü ayrı bir varlığa yerleştirilmemiştir ve kontrol düğümünde yer almaktadır.
Öncelikle yönlendirmenin işe yaradığını görelim:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msBu durumda paketin ağ geçidine gitmesi ve oraya yönlendirilmesi gerektiğinden, örnekte ARP tablosuna bakacağımız ağ geçidinin poppy adresini bulmamız gerekiyor:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Şimdi varış noktası (10.0.1.254) fa:16:3e:c4:64:70 olan trafiğin nereye gönderilmesi gerektiğine bakalım:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Bağlantı noktası 2'nin nereye gittiğine bakalım:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Her şey mantıklı, trafik br-tun'a gidiyor. Bakalım hangi vxlan tüneline sarılacak:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Üçüncü bağlantı noktası bir vxlan tünelidir:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Hangi kontrol düğümüne bakar:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Trafik kontrol düğümüne ulaştı, bu yüzden ona gidip yönlendirmenin nasıl olacağını görmemiz gerekiyor.
Hatırlayacağınız gibi, içerideki kontrol düğümü hesaplama düğümüyle tamamen aynı görünüyordu; aynı üç köprü, yalnızca br-ex'in düğümün dışarıya trafik gönderebileceği fiziksel bir bağlantı noktası vardı. Örneklerin oluşturulması, hesaplama düğümlerindeki yapılandırmayı değiştirdi; düğümlere linux köprüsü, iptables ve arayüzler eklendi. Ağların ve sanal yönlendiricinin oluşturulması, kontrol düğümünün yapılandırmasına da damgasını vurdu.
Bu nedenle, ağ geçidi MAC adresinin kontrol düğümündeki br-int yönlendirme tablosunda olması gerektiği açıktır. Orada olup olmadığını ve nereye baktığını kontrol edelim:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac, qr-0c52b15f-8f bağlantı noktasından görülebilir. Openstack'taki sanal portlar listesine geri dönersek, bu port türü çeşitli sanal cihazları OVS'ye bağlamak için kullanılır. Daha kesin olmak gerekirse, qr, ad alanı olarak temsil edilen sanal yönlendiriciye yönelik bir bağlantı noktasıdır.
Sunucuda hangi ad alanlarının bulunduğunu görelim:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ En fazla üç kopya. Ancak isimlere bakılırsa her birinin amacını tahmin edebilirsiniz. Kimliği 0 ve 1 olan örneklere daha sonra geri döneceğiz, şimdi qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ad alanıyla ilgileniyoruz:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Bu ad alanı daha önce oluşturduğumuz iki dahili ad alanını içerir. Her iki sanal bağlantı noktası da br-int'ye eklendi. Hedef mac adresine göre trafik bu arayüze gittiğinden, qr-0c52b15f-8f bağlantı noktasının mac adresini kontrol edelim.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Yani bu durumda her şey standart yönlendirme yasalarına göre çalışır. Trafik 10.0.2.8 ana bilgisayarına yönlendirildiğinden, ikinci qr-92fa49b5-54 arayüzünden çıkmalı ve vxlan tünelinden hesaplama düğümüne gitmelidir:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Her şey mantıklı, sürpriz yok. 10.0.2.8 ana makinesinin poppy adresinin br-int'te nerede göründüğüne bakalım:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Beklendiği gibi trafik br-tun'a gidiyor, bakalım trafik bundan sonra hangi tünele gidecek:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Trafik-1'i hesaplamak için tünele giriyor. Compute-1'de her şey basit - paket br-tun'dan br-int'e ve oradan da sanal makine arayüzüne gidiyor:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Bunun gerçekten doğru arayüz olup olmadığını kontrol edelim:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
Aslında paketin sonuna kadar gittik. Trafiğin farklı vxlan tünellerinden geçtiğini ve farklı VNI'larla çıktığını fark ettiğinizi düşünüyorum. Bunların ne tür bir VNI olduğunu görelim, ardından düğümün kontrol portunda bir döküm toplayacağız ve trafiğin tam olarak yukarıda anlatıldığı gibi akmasını sağlayacağız.
Dolayısıyla, hesaplama-0 tüneli şu eylemlere sahiptir:load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. 0x16'yı ondalık sayı sistemine çevirelim:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Hesaplama-1'e yönelik tünel şu VNI'ya sahiptir:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. 0x63'ü ondalık sayı sistemine çevirelim:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Şimdi çöplüğe bakalım:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************İlk paket, 192.168.255.19 ana bilgisayarından (compute-0) 192.168.255.15 ana bilgisayarına (kontrol-1) vni 22 ile bir vxlan paketidir; bunun içinde, ana bilgisayar 10.0.1.85'ten ana bilgisayar 10.0.2.8'e bir ICMP paketi paketlenir. Yukarıda hesapladığımız gibi vni çıktıda gördüklerimizle eşleşiyor.
İkinci paket, 192.168.255.15 numaralı ana bilgisayardan (kontrol-1) 192.168.255.26 numaralı ana bilgisayara (compute-1) vni 99 ile bir vxlan paketidir; bunun içinde, 10.0.1.85 numaralı ana bilgisayardan 10.0.2.8 numaralı ana bilgisayara bir ICMP paketi paketlenir. Yukarıda hesapladığımız gibi vni çıktıda gördüklerimizle eşleşiyor.
Sonraki iki paket 10.0.2.8'ten değil 10.0.1.85'den gelen trafiktir.
Yani, sonunda aşağıdaki kontrol düğümü şemasını elde ettik:
Görünüşe göre bu kadar mı? İki ad alanını unuttuk:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Bulut platformunun mimarisinden bahsettiğimiz gibi, makinelerin adresleri otomatik olarak bir DHCP sunucusundan alması iyi olurdu. Bunlar, 10.0.1.0/24 ve 10.0.2.0/24 ağlarımız için iki DHCP sunucusudur.
Bunun doğru olup olmadığını kontrol edelim. Bu ad alanında yalnızca tek bir adres vardır - 10.0.1.1 - DHCP sunucusunun adresidir ve o da br-int'e dahil edilmiştir:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Kontrol düğümünde adlarında qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 içeren süreçlerin olup olmadığına bakalım:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Böyle bir süreç var ve yukarıdaki çıktıda sunulan bilgilere dayanarak örneğin şu anda kiralık olarak nelerimizin olduğunu görebiliriz:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Sonuç olarak, kontrol düğümünde aşağıdaki hizmet kümesini alıyoruz:
Unutmayın - bu sadece 4 makine, 2 dahili ağ ve bir sanal yönlendirici... Şu anda burada harici ağlarımız yok, her birinin kendi ağları olan (örtüşen) bir sürü farklı projemiz var ve elimizde dağıtılmış bir yönlendirici kapatıldı ve sonuçta test tezgahında yalnızca bir kontrol düğümü vardı (hata toleransı için üç düğümden oluşan bir çoğunluk olması gerekir). Ticarette her şeyin "biraz" daha karmaşık olması mantıklıdır, ancak bu basit örnekte nasıl çalışması gerektiğini anlıyoruz - 3 veya 300 ad alanına sahip olmanız elbette önemlidir, ancak tüm alanın işleyişi açısından. yapı, hiçbir şey pek değişmeyecek... ancak siz bir satıcı SDN'sini takmayana kadar. Ama bu tamamen farklı bir hikaye.
Umarım ilginç olmuştur. Herhangi bir yorumunuz/eklemeniz varsa veya açıkça yalan söylediğim bir yer varsa (Ben insanım ve fikrim her zaman öznel olacaktır) - düzeltilmesi/eklenmesi gerekenleri yazın - her şeyi düzelteceğiz/ekleyeceğiz.
Sonuç olarak, Openstack'ı (hem vanilya hem de satıcı) VMWare'in bulut çözümüyle karşılaştırma hakkında birkaç söz söylemek istiyorum - Bu soru bana son birkaç yıldır çok sık soruluyor ve açıkçası, ben zaten bıktım ama yine de. Bana göre bu iki çözümü karşılaştırmak çok zor ama her iki çözümün de dezavantajları olduğunu ve bir çözüm seçerken artılarını ve eksilerini tartmanız gerektiğini kesinlikle söyleyebiliriz.
OpenStack topluluk odaklı bir çözümse, VMWare yalnızca istediğini yapma hakkına sahiptir (okuma - onun için neyin karlı olduğunu) ve bu mantıklıdır - çünkü müşterilerinden para kazanmaya alışkın ticari bir şirkettir. Ancak büyük ve kalın bir AMA var - örneğin Nokia'dan OpenStack'ten kurtulabilirsiniz ve çok az masrafla örneğin Juniper'den (Contrail Cloud) bir çözüme geçebilirsiniz, ancak VMWare'den kurtulmanız pek mümkün değildir . Benim için bu iki çözüm şuna benziyor - Openstack (satıcı), içine konduğunuz basit bir kafes, ancak bir anahtarınız var ve istediğiniz zaman ayrılabilirsiniz. VMWare altın bir kafestir, kafesin anahtarı sahibindedir ve size çok pahalıya mal olacaktır.
Ne ilk ürünü ne de ikinciyi tanıtmıyorum; ihtiyacınız olanı siz seçersiniz. Ancak böyle bir seçeneğim olsaydı, Telekom bulutu için her iki çözümü de seçerdim - BT bulutu için VMWare (düşük yükler, kolay yönetim), bazı satıcılardan OpenStack (Nokia ve Juniper çok iyi anahtar teslim çözümler sağlar) - Telekom bulutu için. Openstack'ı saf BT için kullanmam; bu, serçeleri topla vurmak gibidir, ancak onu kullanmanın fazlalık dışında herhangi bir kontrendikasyonunu görmüyorum. Bununla birlikte, VMWare'i telekomda kullanmak, Ford Raptor'da kırma taş taşımaya benzer; dışarıdan güzeldir, ancak sürücünün bir yerine 10 yolculuk yapması gerekir.
Bana göre, VMWare'in en büyük dezavantajı tamamen kapalı olmasıdır - şirket size nasıl çalıştığı hakkında, örneğin vSAN veya hipervizör çekirdeğinde ne olduğu hakkında herhangi bir bilgi vermeyecektir - onun için kesinlikle karlı değildir - yani, siz asla VMWare konusunda uzman olmayın; satıcı desteği olmadan, mahkum olursunuz (çoğunlukla önemsiz sorular karşısında şaşkına dönen VMWare uzmanlarıyla tanışırım). Benim için VMWare, kaportası kilitli bir araba satın almaktır - evet, triger kayışını değiştirebilecek uzmanlarınız olabilir, ancak yalnızca size bu çözümü satan kişi kaputu açabilir. Kişisel olarak içine sığamayacağım çözümleri sevmiyorum. Kaputun altına girmek zorunda kalmayabileceğinizi söyleyeceksiniz. Evet, bu mümkün, ancak bulutta 20-30 sanal makineden, 40-50 ağdan oluşan büyük bir işlevi birleştirmeniz gerektiğinde size bakacağım, bunların yarısı dışarıya çıkmak istiyor ve ikinci yarısı da istiyor SR-IOV hızlanması, aksi takdirde bu arabalardan birkaç düzine daha fazlasına ihtiyacınız olacak - aksi takdirde performans yeterli olmayacaktır.
Başka bakış açıları da var, dolayısıyla neyi seçeceğinize yalnızca siz karar verebilirsiniz ve en önemlisi, seçiminizin sorumluluğunu siz üstlenirsiniz. Bu sadece benim görüşüm - en az 4 ürünü - Nokia, Juniper, Red Hat ve VMWare - görmüş ve dokunmuş bir kişi. Yani karşılaştırılacak bir şeyim var.
Kaynak: habr.com