Ağ servisleri¶
OpenStack Ağ altyapınızı tasarlarken ilk mimari aşamalarda, uygun güvenlik kontrollerini ve denetim mekanizmalarını belirlemek için fiziksel ağ altyapısının tasarımına yardımcı olacak uygun uzmanlığın bulunmasının sağlanması önemlidir.
OpenStack Ağ, kiracılara kendi sanal ağlarını tasarlama imkânı veren sanallaştırılmış ağ servisleri katmanını ekler. Şu anda, bu sanallaştırılmış servisler, geleneksel ağ eşdeğerlerine göre olgun değiller. Bu sanallaştırılmış servislerin mevcut durumunu, onları sanallaştırılmış ve geleneksel ağ sınırlarında uygulamak zorunda olduğunuz kontrolleri belirlediğinde kabul etmeden önce düşünün.
VLAN’ları ve tünellemeyi kullanarak L2 izolasyonu¶
OpenStack Ağ, trafik ayrımı için kiracı/ağ kombinasyonunda iki farklı mekanizma istihdam edebilir: VLAN’lar (IEEE 802.1Q etiketleme) veya GRE kapsüllemeyi kullanan L2 tünelleri. OpenStack dağıtımınızın kapsamı ve ölçeği, trafik ayrımı veya izolasyon için hangi yöntemi kullanmanız gerektiğini belirler.
VLAN’lar¶
VLAN’lar, belirli bir VLAN ID (VID) alan değeri olan IEEE 802.1Q üstbilgileri içeren belirli bir fiziksel ağdaki paketler halinde gerçekleştirilir. Aynı fiziksel ağı paylaşan VLAN ağları birbirinden L2’de izole edilir ve üst üste binen IP adres alanlarına bile sahip olabilirler. VLAN ağlarını destekleyen her ayrı fiziksel ağ, ayrı bir VID değerlerine sahip ayrı bir VLAN gövdesi olarak ele alınır. Geçerli VID değerleri 1 ile 4094 arasındadır.
VLAN yapılandırma karmaşıklığı OpenStack tasarım gereksinimlerinize bağlıdır. OpenStack Ağ’ın VLAN’ları verimli bir şekilde kullanmasına izin vermek için, bir VLAN aralığı (her kiracıda bir tane için bir tane) tahsis etmeniz ve her hesaplama düğümünün fiziksel geçiş portunu VLAN gövde portuna çevirmeniz gerekir.
Not
Şebekenizin 4094’den fazla kiracıyı desteklemeyi düşünüyorsanız, VLAN etiketleri 4094’ten fazla kiracıya genişletmek için birden fazla ‘hile’ gerektiği için VLAN muhtemelen sizin için doğru seçenek değildir.
L2 tünelleme¶
Ağ tünellemesi, her bir kiracı/ağ kombinasyonunu, bu kombinasyona ait olan ağ trafiğini tanımlamak için kullanılan benzersiz bir “tünel-kimliği” ile saklar. Kiracının L2 ağ bağlantısı fiziksel yerellikten veya alttaki ağ tasarımından bağımsızdır. Trafiği IP paketleri içine sızdırarak, bu trafik Katman 3’ün sınırlarını aşabilir ve önceden yapılandırılmış VLAN’lara ve VLAN kanalına ihtiyaç duymaz. Tünel oluşturma, ağ veri trafiğine karmaşık bir katman katarak, bireysel kiracı trafiğinin bir izleme bakış açısıyla görünürlüğünü azaltır.
OpenStack Ağ şu anda hem GRE hem de VXLAN kapsüllemeyi desteklemektedir.
L2 izolasyonu sağlayan teknoloji seçimi, dağıtımınızda yaratılacak kiracı ağların kapsamına ve boyutuna bağlıdır. Ortamınız sınırlı VLAN ID kullanılabilirliği veya çok sayıda L2 ağına sahipse, tünel açmayı kullanmanız önerilir.
Ağ servisleri¶
Kiracı ağı izolasyonunun seçimi, kiracı servisleri için ağ güvenliği ve kontrol sınırının nasıl uygulandığını etkiler. OpenStack ağ mimarisinin güvenlik durumunu iyileştirmek için şu ek ağ servisleri mevcut veya şu an geliştirme aşamasındadır.
Erişim kontrol listeleri¶
OpenStack Hesaplama, eski nova-network servisiyle konuşlandırıldığında doğrudan kiracı şebeke trafiği erişim kontrollerini destekler veya OpenStack Ağ servisine erişim denetimini erteleyebilir.
Not: eski nova-network güvenlik grupları, bir örnekteki tüm sanal arabirim portlarına iptables kullanarak uygulanır.
Güvenlik grupları, yöneticilere ve kiracılara bir sanal arabirim bağlantı noktasından geçmesine izin verilen trafik türünü ve yönünü (giriş/çıkış) belirtme olanağına olanak tanır. Güvenlik grupları kuralları, durum bilgisi olan L2-L4 trafik filtreleridir.
Ağ servisi kullanırken, bu serviste güvenlik gruplarını etkinleştirmenizi ve Hesaplama servisinden devre dışı bırakmanızı öneririz.
L3 yönlendirme ve NAT¶
OpenStack Ağ yönlendiricileri, birden fazla L2 ağını bağlayabilir ve ayrıca bir veya daha fazla özel L2 ağını, İnternet erişimi için ortak bir ağ gibi paylaşılan bir harici ağa bağlayan bir ağ geçidi sağlayabilir.
L3 yönlendirici, yönlendiriciyi dış ağlara bağlayan ağ geçidi portlarında temel Ağ Adresi Çevirisi (NAT) yetenekleri sağlar. Bu yönlendirici, varsayılan olarak tüm trafiğe SNAT (Statik NAT) yapar ve dış ağdaki genel bir IP’den yönlendiriciye bağlı diğer alt ağlardan birindeki özel bir IP’ye statik bire bir eşleme oluşturan kayan IP’leri destekler.
Kiracı VM’lerin daha ayrıntılı bağlantısı için kiracı L3 yönlendirmesi ve Yüzen IP’ler için kaldıracı kullanmamız önerilir.
Hizmet Kalitesi (QoS)¶
Varsayılan olarak, Hizmet Kalitesi (QoS) ilkeleri ve kuralları bulut yöneticisi tarafından yönetilir; kiracılar belirli QoS kuralları oluşturamaz veya politikalara belirli portlar ekleyemezler. Bazı haberleşme uygulamaları gibi bazı kullanım durumlarda, yönetici kiracılara güvenebilir ve bu nedenle kendi ilkelerini portlara ekleyip bunlara portlara bağlayabilir. Bu, policy.json dosyasını değiştirerek ve uzantı ile yayınlanacak özel belgelendirmeler ile başarılabilir.
Ağ hizmeti (neutron), Liberty ve sonrasında bant genişliği sınırlayıcı QoS kurallarını desteklemektedir. Bu QoS kuralı QosBandwidthLimitRule olarak adlandırılır ve saniye başına kilobit cinsinden ölçülen iki negatif olmayan tamsayı kabul eder:
max-kbps: bant genişliğimax-burst-kbps: patlatma arabelleği
QoSBandwidthLimitRule, neutron Open vSwitch, Linux köprüsü ve tek kök giriş/çıkış sanallaştırma (SR-IOV) sürücülerinde uygulanmıştır.
Newton’da QoS kuralı QosDscpMarkingRule` eklendi. Bu kural, IPv4’deki (RFC 2474) hizmet başlığı türüne Ayrılmış Hizmet Kodu Noktası (DSCP) değerini ve kuralın uygulandığı bir sanal makine bırakan tüm trafikteki IPv6 üzerindeki trafik sınıfı üst bilgisini işaretler. Bu, tıkanıklığı gidermek durumunda ağları geçtiği için bir paketin bırakma önceliğini belirten 21 geçerli değer içeren 6 bitlik bir başlıktır. Geçerli veya geçersiz trafiği erişim kontrol listesine uydurmak için güvenlik duvarları tarafından da kullanılabilir.
Port yansıtma servisi, bir porta giren veya çıkan bir paket kopyasını, genellikle yansıtılan paketlerin özgün hedeflerinden farklı olan başka bir porta göndermeyi içerir. Service-as-a-Service (TaaS), OpenStack ağ servisinin (neutron) bir uzantısıdır. Kiracı sanal ağlar için uzaktan port yansıtma özelliği sağlar. Bu hizmet öncelikle kiracıların (veya bulut yöneticisinin) karmaşık sanal ağları hata ayıklamasına ve kendileriyle ilişkili ağ trafiğini izleyerek VM’lerinde görünürlük kazanmalarına yardımcı olmak için tasarlanmıştır. TaaS, kiracı sınırlarını ve ayna oturumlarını, birden çok hesaplama ve ağ düğümü arasında kapsayacak kapasiteye sahiptir. Çeşitli ağ analitiği ve güvenlik uygulamalarına veri tedarik etmek için kullanılabilen temel bir altyapı bileşenidir.
Yük dengeleme¶
OpenStack Ağ’daki diğer bir özellik de hizmet-olarak-yük-dengeleyici (LBaaS). LBaaS referans uygulaması HA-Proxy’ye dayalıdır. Sanal arabirim bağlantı noktaları için geniş L4-L7 işlevselliği sağlamak için OpenStack Ağ’daki uzantılar için geliştirilmiş üçüncü taraf eklentileri bulunmaktadır.
Güvenlik duvarları¶
FW-as-a-Service (FWaaS), OpenStack Ağ’ın Kilo sürümü için deneysel bir özellik olarak düşünülür. FWaaS, tipik olarak güvenlik grupları tarafından sağlananlardan çok daha kapsamlı olan tipik güvenlik duvarı ürünleri tarafından sağlanan zengin güvenlik özelliklerini yönetme ve kullanma ihtiyacına cevap verir. Hem Freescale hem de Intel, bu bileşeni Kilo sürümünde desteklemek için OpenStack Ağ’da üçüncü parti eklentileri geliştirmiştir. FWaaS yönetimiyle ilgili daha ayrıntılı bilgi için, OpenStack Yönetici Kılavuzu’ndaki Hizmet Olarak Güvenlik Duvarları (FWaaS) genel bakış belgesine bakın.
Bir OpenStack Ağ altyapısı tasarlanırken mevcut ağ servislerinin mevcut özelliklerini ve sınırlamalarını anlamanız önemlidir. Sanal ve fiziksel ağlarınızın sınırlarını anlamak, ortamınıza gerekli güvenlik kontrolleri eklemenize yardımcı olacaktır.
Ağ servisleri uzantıları¶
Açık kaynak topluluğu veya OpenStack Ağ ile çalışan SDN şirketleri tarafından sağlanan bilinen eklentilerin bir listesi OpenStack neutron eklentileri ve sürücüler wiki sayfası adresinde bulunabilir.
Ağ servisleri sınırlandırmaları¶
OpenStack Networking aşağıdaki bilinen sınırlamaları içerir:
- Örtüşen IP adresleri
neutron-l3-agent veya neutron-dhcp-agent çalıştıran düğümler çakışan IP adresleri kullanıyorsa, bu düğümler Linux ağ ad alanlarını kullanmalıdır. Varsayılan olarak, DHCP ve L3 aracıları Linux ağ ad alanlarını kullanır ve kendi ilgili ad alanlarında çalışır. Bununla birlikte, ana makine birden fazla ad alanını desteklemiyorsa, DHCP ve L3 aracıları ayrı bilgisayarlarda çalıştırılmalıdır. Bunun nedeni, L3 aracısı ve DHCP aracı tarafından oluşturulan IP adresleri arasında hiçbir yalıtım bulunmamasıdır.
Ağ ad alanı desteği yoksa, L3 aracısının bir başka kısıtlaması yalnızca tek bir mantıksal yönlendiricinin desteklenmesidir.
- Çoklu sunuculu DHCP aracı
OpenStack Ağ, yük dengeleme özelliğine sahip birden fazla L3 ve DHCP aracını destekler. Bununla birlikte, sanal makinenin yerinin sıkı bağlanması desteklenmemektedir. Başka bir deyişle, varsayılan Sanal Makine zamanlayıcı, sanal makineler oluştururken aracıların konumunu dikkate almaz.
- L3 aracıları için IPv6 desteği yok
Birçok eklenti tarafından L3 iletmeyi uygulamak için kullanılan neutron-l3-agent yalnızca IPv4 iletmeyi destekler.
