237: vExpert 2017 duyurusu

vexpert2017

8 Şubat 2017 tarihi itibari ile, 2017 vExpert listesi yayımlandı. Öncelikle bir kere daha bu ünvana layık görüldüğüm için son derece mutluyum, 2016 senesi içerisinde gerçekleştirmiş olduğumuz webinar’ların, VMUG eforlarının ve yazılmış yazıların bir karşılığının olduğunu ve takdir gördüğünü görmek son derece memnuniyet verici. Peki nedir bu vExpert programı? VMware’ın kendi cümleleri ile tanımlamaya çalışırsak;

The VMware vExpert program is VMware’s global evangelism and advocacy program. The program is designed to put VMware’s marketing resources towards your advocacy efforts. Awards are for individuals, not companies, and last for one year.

Elbette vExpert ünvanına layık görülmek yoğun efor gerektiren bir konu, ister blog yazarı olun ister VMUG grup lideri veya aktif bir üyesi. Ancak vExpert sıfatının beraberinde getirdiği ciddi avantajlar da söz konusu, bunları kısaca listeyelecek olursak;

  • Piyasada uzmanlığınızı vExpert ünvanı ile belgelemek
  • Pat Gelsinger (CEO) tarafından imzalı vExpert sertifikası
  • Demo/lab ortamları için 365 günlük geçici VMware lisansları
  • VMware partner’ları ile özel webinar ve NFR lisansları
  • VMware partner’larından özel hediyeler
  • Özel #Slack kanalına giriş yetkisi
  • Communities.vmware.com kanalında özel forumlara giriş yetkisi
  • Özel beta sürümlerine erişim yetkisi (ekstra onaya tabi olacak şekilde)
  • VMworld’lere katılım şansı (blogger pass) ancak çok kısıtlı miktarda
  • VMworld öncesi özel vExpert buluşması

Son olarak bahsetmek istediğim bir konu daha var, madalyonun bir de öteki yüzü. Bir süredir, vExpert seçimlerinin yeterince hassas yapılmadığı konusunda da farklı görüşler oluşmaya başladı. Özellikle Eric Siebert yazdığı makalesinde bunu açık bir şekilde dile getirdi ve hatta vExpert ünvanında kategorizasyona gidilmesi ile ilgili de bir önerisi oldu. İlerleyen dönemlerde bunun değerlendirilip değerlendirilmeyeceği konusunda net bir fikrim yok ancak objektif olarak düşündüğümüzde haklı olduğu noktalar olduğunu görebiliyoruz. Bu konuda yorumu sizlere bırakıyorum.

Her şeye rağmen, bu elit grubun bir üyesi olmaktan gurur duyuyorum ve emeği geçen herkese teşekkür ediyorum.

Kategoriler:VMware Etiketler:

236: iovDisableIR parametresi hakkında

07.02.2017 1 yorum

Interrupt Remapping, Intel VT-d ve AMD IOMMU tarafından implemente edilen ve I/O cihazlarından gelen interrupt taleplerinin daha verimli bir şekilde sanal sunuculara yönlendirilmesini sağlayan bir özelliktir. ESXi 4.1 ve sonrası sürümlerde, VMware tarafından da varsayılan olarak desteklenmektedir. Buraya kadar her şey güzel iken, sıkıntılı taraf her donanım bu kodu desteklememektedir ve uyumlu olmayan bir konfigürasyon sanal sunucularda problemlere sebebiyet verebilir. VMware’ın makalesi bu konuyu detaylı olarak ifade etmektedir ve bu tip durumlarda önerilen, bir adet kernel parametresi ile bu özelliğin kapatılması yönündedir.

esxcli system settings kernel set –setting=iovDisableIR -v TRUE

Not: Konu ile ilgili güzel ve gayet detaylı bir makale de Adem Yetim’in zamanında yazmış olduğu bir makaledir, buradan erişebilirsiniz.

Ancak tam tersi senaryonun problem yarattığı durumlar da vardır. Örnek olarak, HPE DL/ML/BL Gen8/9 sunucularda bu özelliğin pasif bırakılmaması yönünde yazılmış tavsiye niteliğinde makaleler de bulunmaktadır. Hatta bu özellik kapatıldığında, yüksek oranda LINT1/NMI hatası ve sonucunda PSoD almamız muhtemeldir.

iovdisableir

Burada bahsetmek istediğim kritik nokta, uzun süredir varsayılan olarak FALSE olarak tanımlı olan ve sonuç olarak Interrupt Remapping özelliğini aktif tutan iovDisableIR kernel parametresinin, “ESXi 6.0 Patch 4” sonrasında TRUE olarak değiştirilmiş ve HPE sistemlerde PSoD’ye sebebiyet verebilecek olmasıdır (Güncelleme: ESXi 5.5 için de benzer durum söz konusu görünüyor).

Bu yüzden, tüm sistemler üzerinde bu parametrenin değerinin ne olduğu ve donanım üreticisinin tavsiyeleri doğrultusunda tanımlanmış olup olmadığı bir hayli önem kazanıyor. Aşağıdaki powershell fonksiyonu ile tanımlamaları hızlı bir şekilde görebiliriz.


function Get-iovDisableIR {
$VMHosts = Get-VMHost | Sort-Object Name
foreach ($VMHost in $VMHosts) {
$esxcli = Get-EsxCli -VMHost $VMHost
$item = $esxcli.system.settings.kernel.list($false,"iovDisableIR")
Write-Host ("{0} ({1}) -> Def:{2}-Con:{3}-Run:{4}" -f $VMHost.Name,$VMHost.Build,$item.Default,$item.Configured,$item.Runtime)
}
}

Bu fonksiyon ile vCenter sunucusuna bağlı tüm ESXi sunucuların isim ve build numarası ile birlikte, iovDisableIR parametresinin Default, Configured ve Runtime değerlerini görebilirsiniz.

Aşağıdaki örnekte, son yama geçilmemiş iki adet ESXi 6.0 sunucu ile diğer sunucular arasındaki farkı net olarak görebiliriz, versiyon numarası daha düşük ve varsayılan değer FALSE olarak. Güncellenmiş sunucularda ise bu değer TRUE görünmektedir.

iovdisableir2

Sözün özü, eğer HPE DL/ML/BL Gen8/9 sunucunuz varsa, PSoD almamak adına önerilen workaround, bu parametrenin yama sonrasında yeniden FALSE olarak değiştirilmesi ve sunucunun restart edilmesi. Ancak VMware ve HPE bu konuda beraber çalışıyorlar, ilerleyen dönemlerde belki bir BIOS güncellemesi olarak belki de farklı bir yama ile durumun daha kalıcı olarak çözülmesini bekleyebiliriz. Bu zamana kadar

ESXi üzerinden Interrupt Remapping özelliğinin yeniden açılması için:

esxcli system settings kernel set –setting=iovDisableIR -v FALSE

Powercli ile toplu bir şekilde yeniden açılması için:


function Disable-iovDisableIR {
$VMHosts = Get-VMHost | Sort-Object Name
foreach ($VMHost in $VMHosts) {
$esxcli = Get-EsxCli -VMHost $VMHost
$item = $esxcli.system.settings.kernel.set("iovDisableIR","FALSE")
Write-Host ("{0}: iovDisableIR is disabled, Please reboot the server" -f $VMHost.Name)
}
}

Kategoriler:VMware Etiketler:,

235: vSphere Docker Volume v0.10

Konteyner yapılarının en verimli olduğu kullanım alanları, üzerlerinde veri tutmayan, kullanılıp atılabilen (disposable) uygulama parçalarını barındırdığı senaryolar. Ancak her konteyner bileşeni için bu durum elbette geçerli olamayacaktır, hatta çoğu senaryoda konteyner yaşam döngüsü ile verilerin yaşam döngüsü birbirinden bağımsız olması gerekecektir. Bu ihtiyacı gidermek amacı ile Docker, 1.8.0 versiyonu ile birlikte “volume plugin” mekanizmasını hayata geçirdi. Bu sayede, ilgili konteyner yok olsa bile verilerin devamlılığı sağlanabiliyor.

Volume plugin mekanizamasını hayata geçirirken, Docker kendi sürücüsünü varsayılan olarak entegre etti, ancak üçüncü parti firmaların da geliştirmeleri sonucunda kendi sürücülerini de sisteme dahil edebilmelerine de olanak sağladı (örnek: Flocker, ConvoyRex-Ray, vb). Eğer Docker’ın kendi standard sürücüsünü kullanmak istersek, aşağıdaki şekilde bir konteyner çalıştırabiliriz.

docker run –rm -it -v /kaynak_klasor:/hedef_klasor busybox

Bu komut sonrasında shell açılacaktır ve host üzerinde yer alan kaynak_klasor, konteyner içerisinde hedef_klasor olarak mount edilecektir. Shell’den çıktığımızda ise konteyner yok olacak ancak klasör üzerinde yapmış olduğumuz değişiklikler saklanacaktır. Bu etkili bir yöntem olmakla birlikte önemli bir dezavantajı vardır, üzerinde çalışılan hosta bağımlıdır, bu da konteynerlerin en önemli avantajı sayılabilecek taşınabilirlik özelliğini kaybetmesine sebep olacaktır.

docker-volume-vsphere0vSphere Docker Volume, vSphere üzerinde oluşturulan Docker konteynerler için persistent volume oluşturabilmek amacı ile ilerleyen açık kaynak bir projedir ve şu anda 0.10 versiyonundadır. vSphere üzerinde vSAN, VMFS ve NFS gibi tanımlı diskler üzerinde tanımlanabilir ve bu sayede erişilebilirlik ve yedeklilik unsurlarını beraberinde Docker ekosistemine taşıyabilir. Temel olarak yaptığı, docker komutları ile bir VMDK oluşmasını tetiklemek ve konteynerlerin bu VMDK’e erişimini sağlamak.

Sistemin çalışabilmesi için üç adet bileşene ihtiyacımız var.

  • vSphere Data Volume Driver: ESXi üzerine VIB paketi olarak kurulur.
  • vSphere Docker Volume Plugin: Docker Host üzerinde RPM paketi olarak kurulur.
  • Docker Host üzerinde vmtools servisinin kurulmuş olması gerekir.

docker-volume-vsphere1

Paketleri indirmek için, projenin GitHub üzerinde bulunan sürüm sayfasını kullanabiliriz. ESXi 6.0 ve PhotonOS kullanacağınız senaryoda indirmemiz gereken paketler aşağıdaki gibi olacaktır.

VIB paketinin kurulumu: İndirdiğimiz offline bundle paketini esxi sunucusunun erişebileceği bir yere kopyalar ve esxcli komutu ile kurabiliriz. Bu paket imzalanmamış olduğundan dolayı –no-sig-check parametresini kullanmamız gerekecektir. Restart gerektirmeyecektir ve servis otomatik başlayacaktır.

esxcli software vib install -d /tmp/vmware-esx-vmdkops-0.10.04f085b.zip –no-sig-check -f
/etc/init.d/vmdk-opsd status

RPM paketinin kurulması: PhotonOS senaryosunda vmtools kurulu geldiğinden sadece rpm paketinin kurulması yeterli olacaktır. Docker versiyon gereksinimi 1.9 ve ötesidir ancak PhotosOS ile birlikte 1.11 versiyonu geldiğinden dolayı sorun olmayacaktır.

rpm –install docker-volume-vsphere-0.10.04f085b-1.x86_64.rpm
systemctl status docker-volume-vsphere

Tüm hazırlıklar tamamlandıktan sonra docker komutları ile vmdk seviyesinde persistent disk yaratabilir durumdayız. İlgili komut dizilimi ve önemli olabileceğini düşündüğüm parametreler aşağıdaki gibidir. İsim ve sürücü haricindeki parametreler zorundu değildir.


docker volume create --name=YeniVolume --driver=<vmdk|photon> \
-o size=boyut<mb|gb|tb> \
-o diskformat=<zeroedthick|thin|eagerzeroedthick> \
-o vsan-policy-name=politika_ismi \
-o attach_as=<independent_persistent|persistent> \
-o access=<read-only|read-write> \
-o clone-from=BaskaVolume

Gereksinimleri tamamlayıp, temel yapısı üzerinde de durduktan sonra, artık PhotonOS bir sunucu üzerinde volume oluşturabiliriz. Aşağıdaki komut, VMFS01 isimli datastore üzerinde bir vmdk oluşturacaktır. ls ve inspect komutları ile de detaylarını görebiliriz.

docker volume create –driver=vmdk –name=vol1@VMFS01 -o size=1gb

docker-volume-vsphere2

Artık bu volume içerisine veri yazabiliriz. Aşağıdaki komut bir adet photon imajı açacak, vol1 isimli volume /klasor1 olarak mount edecek, hosts dosyasını kopyalayacak ve sonrasında oluşturulan konteyneri yok edecektir. Normal şartlarda imajın yazılabilir katmanına yazılan verinin silinmesini bekleriz ancak docker volume üzerine yazdığımız bu veri varlığını koruyacak ve yeni, sıfır bir konteyner oluşturduğumuzda veri erişilebilir olacaktır. Bir sonraki komutta ise yeni bir konteyner oluşturup, bu sefer /klasor2 olarak mount edeceğiz ve verinin erişilebilir olduğunu göreceğiz.

docker run –rm -v vol1:/klasor1 demoharbor.demo.local/library/photon:1.0 cp /etc/hosts /klasor1/deneme
docker run –rm -v vol1:/klasor2 demoharbor.demo.local/library/photon:1.0 cat /klasor2/deneme

docker-volume-vsphere3

vSphere tarafındaki görüntüsü ise, VMFS01 datastore’u içerisinde, vol1 isimli bir vmdk dosyası olacaktır.

docker-volume-vsphere4

Kategoriler:Docker, VMware Etiketler:

234: PhotonOS üzerine docker-compose kurulumu

dockercompose0PhotonOS, tek bir konteyner çalıştırma stratejisi ile optimize edilmiş bir işletim sistemi, Docker Compose ise, birden fazla docker konteyner bileşenini içeren uygulamaları tanımlamak ve çalıştırmak için kullanılan bir araç. Dolayısı ile, VMware’ın CNA stratejisi içerisinde PhotonOS ile birlikte varsayılan olarak docker-compose aracının bulunmamasını normal karşılayabiliriz. Ancak test amaçlı veya bir takım özel senaryolar için docker-compose aracına ihtiyaç duyabiliriz, örnek olarak Harbor Projesi, PhotonOS üzerinde çalışır ve üzerinde docker-compose ile tanımlanmış altı adet konteyner bulunur.

Kurulum için aklımıza gelen ilk yöntem, PhotonOS’in standard paket yöneticisi tdnf olur. Ancak tdnf ile arama yaptığımızda, repolar içerisinde bulamayacağız.

dockercompose1

Bu noktada yapabileceğimiz, GitHub repoları üzerinden indirmek ve dosya seviyesinde gerekli işlemleri yapmak. Bu adım için sunucunun internet erişiminin olması gerekecektir.

curl -L “https://github.com/docker/compose/releases/download/1.9.0/docker-compose-$(uname -s)-$(uname -m)” -o /usr/local/bin/docker-compose

dockercompose2

Eğer sunucumuzun internet erişimi bulunmuyorsa, manuel olarak bu dosya indirilebilir ve ilgili alana scp yardımı ile kopyalayabiliriz. Bu aslında yukarıda yer alan curl komutunun manuel yolla işletilmesinden farklı birşey değildir.

Bu işlemlerden sonra docker-compose aracının beklendiği gibi çalıştığını görebileceğiz.

Kategoriler:VMware Etiketler:,

233: VICui plugin hakkında

VICui, vSphere Integrated Containers bünyesinde kurulan VCH’ların ve konteynerlerin, vSphere yöneticisine yönelik izlenebilirlik yeteneklerini artırmayı hedefleyen bir Web Client eklentisidir. Daha önceden klasör olarak indirmiş ve VCH kurulumlarında kullanmış olduğumuz vic klasörü içerisinde, plugin kurulumu ile ilgili paketler de yer almaktadır. Kurulum Windows tabanlı vCenter ile appliance tabanlı vCenter arasında farklılık gösterecektir. Ben kendi ortamım doğrultusunda, appliance tabanlı olan vCenter ile vic-machine olarak PhotonOS kullandığım senaryoyu kaleme alacağım.

Kurulumu gerçekleştirmeden önce kontrol etmemiz gereken önemli konu, vCenter appliance sunucusunun root kullanıcısının shell’inin bash olması gerektiğidir. Eğer varsayılan olarak appliancesh bırakılmış ise, SSH üzerinden gerçekleştirilecek erişim başarısız olacak ve işlem devam edemeyecektir. Bunu değiştirmek için, vCenter sunucusu üzerinde SSH yapıldıktan sonra aşağıdaki komutlar çalıştırılır;

shell.set –enabled true
shell
chsh -s /bin/bash root

İşlem bittikten sonra ise eğer isterseniz aşağıdaki komut ile varsayılan shell’e dönebilirsiniz.

chsh -s /bin/appliancesh root

Gerekli önkoşulu sağladıktan sonra kurulum kısmına geçebiliriz. Vic-machine olarak tanımladığımız sunucuda, vic klasörü altında yer alan kurulum paketleri arasında bulunan konfigürasyon dosyasına, vCenter sunucusunun bilgisini yazmamız gerekecektir. IP kısmı zorunlu, diğer parametreler opsiyoneldir. Aşağıda bunun örneğini görebilirsiniz.

vicpluginSonrasında aşağıdaki komut dizilimi ile install.sh scriptini çalıştırılır. Öncelikle install.sh scriptinin çalıştırılabilir olması gerekmektedir. Bu script kendi içerisinde de vic-ui-linux.sh scriptini çağırır, bu yüzden bu scriptin de yetkilerinin düzenlenmesi gerekir, yoksa yetki hatası sonucu işlem yarıda kalacaktır.

chmod +x install.sh
chmod +x ../../vic-ui-linux.sh
./install.sh

Scripti çalıştırdıktan sonra aşağıdaki gibi bir çıktı ile karşılaşmayı bekleyebiliriz.

vicplugin2

Bu kurulum işlemi esnasında bizden üç kere şifre girmemizi isteyecektir;

  • Bash’in açık olup olmadığını test etmek için, eğer bash shell açık değilse kurulum devam etmeyecektir.
  • SSH üzerinden gerekli dosyaları kopyalamak için.
    • Kaynak klasör: /root/vic/ui/vsphere-client-serenity/
    • Hedef klasör: /etc/vmware/vsphere-client/vc-packages/
  • Dosya ve klasörlerin yetkilerinin düzenlenmesi için.

Bu adımları başarılı geçtikten sonra com.vmware.vicui.Vicui isimli bir eklentinin eklenmiş olduğunu göreceğiz.

vicplugin4

Web Client tarafında ise farkettiğim, VIC’in daha önceki beta versiyonlarında daha zengin ve bilgilendirici bir arayüzün bizlerle birlikte olduğu idi, 2015 yılında yayınlanan bu makalede görüldüğü gibi. Güncel versiyon olan 0.8.0 versiyonunda karşılaştığım durum ise, VCH endpoint VM ve konteyner VM’lere tıkladığımızda, özet sayfasında bir portlet vasıtası ile bize ekstra bilgiler sunması. Ancak yeni VCH oluşturmak gibi opsiyonları göremedim.

vicplugin3

Kategoriler:VMware Etiketler:,

232: VCH ve docker entegrasyonu

En son VIC-Engine yapısından ve temel bileşeni olan Virtual Container Host’dan (VCH) bahsetmiştik. Tekrar etmek gerekirse VCH, vSphere platformu üzerinde konteynerlerin yaşam döngülerini yönetmeyi amaçlayan araçları ve sistem kaynaklarını (CPU ve bellek gibi) barındıran mantıksal bir yapıdır. Aynı zamanda, kullanıcılara Docker API erişimi sağlar ve Docker Hub üzerinden imajların yönetimine izin verir (VCH detayları için lütfen tıklayın).

Bir vSphere kümesi üzerinde, örnek olarak aşağıdaki komut dizilimi ile bir VCH oluşturabiliriz. Bu komut sonrasında ilgili kaynak havuzu içerisinde bir vApp oluşacak ve bu vApp içerisinde bir adet appliance VM konumlandırılacak (VCH endpoint VM).


./vic-machine-linux create \
--name=democvh01 \
--target=demovc.demo.local/DEMO.Datacenter \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--user=orcunuso \
--ops-user=svcvic \
--ops-password=Password! \
--compute-resource=DEMO.Cluster/DEMO.Vic \
--image-store=VMFS01/VCH/demovch \
--volume-store=VMFS01/VCH/demovch:default \
--bridge-network=DPG.Vlan200 \
--public-network=DPG.Vlan100 \
--client-network=DPG.Vlan100 \
--management-network=DPG.Vlan100 \
--dns-server=10.1.94.10 \
--public-network-ip=10.1.93.24 \
--public-network-gateway=10.1.93.1/24 \
--bridge-network-range=172.16.0.0/12 \
--appliance-cpu=2 \
--appliance-memory=4096 \
--registry-ca=/root/vic/ca.crt \
--tls-cname=demovch01.demo.local \
--certificate-key-size=2048 \
--organization=DEMO \
--no-tlsverify

Kullandığım parametreleri detaylandırmak gerekirse;

Satır 2: Kurulacak VCH ismi
Satır 3: Hedef vCenter ve datacenter bilgisi
Satır 4: Hedef vCenter SSL sertifika parmak izi
Satır 5: Kurulumu yapacak kullanıcının ismi. Şifreyi kurulum esnasında soracaktır ancak eğer istersek –password parametresi ile de belirtebiliriz.
Satır 6-7: vSphere üzerinde VCH operasyonlarını yapacak kullanıcı adı ve şifresi
Satır 8: Hedef küme ve resource pool bilgisi
Satır 9: Konteyner imaj ve VM dosyalarının saklanacağı alan
Satır 10: Persistent volume oluşturulacaksa, bunların saklanacağı alan
Satır 11: Bridge network olarak kullanılacak portgroup bilgisi. Bridge network, konteyner VM’lerin kendi aralarında ve VCH VM ile konuşabilecekleri özel bir L2 network olmalıdır.
Satır 12: Public network olarak kullanılacak portgroup bilgisi. Public network, konteyner VM’lerin dış dünya ile iletişim kurdukları network. Eğer port mapping kullanılıyorsa, ilgili portun expose edildiği arayüzdür.
Satır 13: Client network olarak kullanılacak portgroup bilgisi. Client network, Docker istemcilerinin API komutlarını yönlendirdikleri networkdür.
Satır 14: Management network olarak kullanılacak portgroup bilgisi. Management network, VCH’ın vCenter ve ESXi sunucular ile konuştuğu networkdür.
Satır 15-17: VCH endpoint VM için yaptığımız network konfigürasyonu. DHCP kullanıyorsak gerek duymayabiliriz.
Satır 18: Bridge network için tercih ettiğimiz IP subnet’i.
Satır 19-20: VCH endpoint VM için tanımlayabileceğimiz kaynak değerleri.
Satır 21: İçeride kullandığımız registry sunucusunun SSL sertifikası.
Satır 22: VCH için oluşturulacak sertifikanın cname bilgisi
Satır 23: VCH için oluşturulacak sertifikanın anahtar boyutu
Satır 24: VCH için oluşturulacak sertifikanın organizasyon bilgisi
Satır 25: İstemci erişimleri için TLS doğrulamasının zorunlu tutulmaması.

vCenter ortamımızda bulunan VCH’ları listelemek veya silmek istersek de, aşağıdaki komut dizilimlerini kullanabiliriz.


./vic-machine-linux ls \
--target=demovc.demo.local \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--user=orcunuso

./vic-machine-linux delete \
--target=demovc.demo.local/DEMO.Datacenter \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--name=demovch \
--compute-resource=DEMO.Cluster/DEMO.Vic \
--user=orcunuso \
--force

Temel olarak VCH ile neler yapabileceğimizi gördük, şimdi ise docker API endpoint olarak neler yapabileceğimize bakalım. Aslında temelde kullandığımız docker remote API komutlarından farklı bir komut kullanmayacağız. Aşağıdaki örnekteki gibi, çalıştıracağımız komutlara aynı cevapları verecektir. TLS üzerinden erişim sağladığımızdan dolayı 2376 portunu kullanıyoruz. Eğer –no-tls parametresi ile oluşturmuş olsaydık, 2375 portunu kullanmamız gerekecekti.

docker -H demovch01.demo.local:2376 –tls info

virtualcontainerhost1

Burada dikkat çeken nokta, toplam bellek ve CPU kapasitesinin kümenin toplamına eşit olması. Eğer VCH bazında kısıtlamak istersek (ki multi-tenant bir yapıda anlamlı olabilir), vApp seviyesinde limit tanımlamamız, bu maksimum değerlerin değişmesini tetikleyecektir.

Şimdi de bir adet konteyner çalıştıralım. Bu arada her komut için -H parametresini kullanmak istemeyebiliriz, bunun için ortam değişkeni tanımlamak işimizi kolaylaştıracaktır.

export DOCKER_HOST=demovch01.demo.local:2376
docker –tls run –name Nginx_Konteyner -d -p 8080:80 \
demoharbor.demo.local/library/vmnginx:1.0

virtualcontainerhost2

Bu örnekte, nginx imajını daha önceden 1.0 etiketi ile göndermiş olduğum harbor registry sunucusundan çağırdım. Arka planda gerçekleştirilen ise, vApp içerisinde, PhotonOS temelli bir işletim sisteminin, vic dosyaları içerisinde daha önceden gördüğümüz bootstrap.iso isimli liveCD imajı ile açılması ve üzerinde nginx imajının ayağa kaldırılması oldu. Network erişimi, bridge network olarak tanımladığımız portgroup üzerinden port mapping şeklinde gerçekleşti, yani VCH endpoint VM’e 8080 portundan gelen trafiğin 172’li network üzerinden bu konteyner sunucusunun 80 portuna yönlendirilmesi şeklinde. İçeriden dışarıya olan erişim ise, yine VCH sunucusunun public arayüzü üzerinden SNAT (Source NAT) yapılarak gerçekleşecek. vCenter üzerindeki görüntüsü ise aşağıdaki gibi olacaktır.

virtualcontainerhost3

Son olarak, oluşturduğumuz VCH, bize web tabanlı bir arayüz de sunmaktadır. VCH sunucusuna bir tarayıcı üzerinden 2378 portu ile erişip temel sağlık bilgilerine ve loglara ulaşabiliriz.

Günün sonunda VIC ile, standard bir docker host üzerinde gerçekleştirilebilecek hemen hemen tüm işlemlerin, çok benzer mantıklar ile vSphere katmanına uyarlanmış olduğunu görebiliyoruz.

Kategoriler:VMware Etiketler:,

231: VIC-engine ve Virtual Container Host kurulumu

07.01.2017 1 yorum

Şu ana kadar genel olarak VIC (vSphere Integrated Containers) stratevic0jisinden ve özel bir registry hizmeti veren Harbor uygulamasından bahsettik. Şimdi ise işin asıl gerçekleştiği katmandan yani VICE (VIC-Engine) katmanından bahsedelim.

VICE, vSphere özelinde oluşturulmuş bir konteyner çalıştırma platformudur, yazılım geliştiriciler aşina oldukları docker komutları ile konteyner oluşturma ve paketleme yapabilir ve vSphere platformu üzerinde çalıştırabilirler. Bu yapının getirdiği en büyük avantaj, vSphere ortamının sahip olduğu HA, DRS, yedekleme, izleme, izolasyon, güvenlik gibi özellikleri doğal olarak bünyesinde barındırmasıdır. Bunun ile beraber sistem yöneticileri de, yine aşina oldukları yöntemler ile sanal sunucu içerisine 1:1 oranında konumlandırılmış bu konteynerleri yönetebilir ve izleyebilirler. Daha teknik bir ifade ile tanımlamak gerekirse, docker API’ları ile vSphere API’ları arasında bir köprü görevi görür.

VIC modülünü vSphere 6.0 veya 6.5 üzerine kurabilirsiniz. Ortam bileşenlerinden kısaca bahsetmek gerekirse;

VIC-Machine: Oluşturacağımız Virtual Container Host (VCH)’ların yaşam döngülerini yöneteceğimiz aracın adıdır. Bu Windows, Linux veya MacOS bir makine olabilir. My Vmware üzerinden indireceğiniz paketi istediğiniz platformda açabilir ve komut satırından çalıştırabilirsiniz.

Virtual Container Host: VCH, docker çalıştıran bir linux sunucunun vSphere karşılığıdır, tabi bir takım farklar ile. Öncelikle linux tabanlı bir docker host, linux sunucunun kaynakları ile sınırlı iken, VCH, vSphere cluster veya resource pool kaynakları ile sınırlıdır, vSphere karşılığı ise vApp’dir. Kendisini vApp olarak konumlandırdığından dolayı da, kaynaklarını istediğimiz gibi şekillendirebiliriz. Bir küme veya resource pool içerisinde birden fazla VCH kurabiliriz, aynı geleneksel yöntemde birden fazla linux docker host kurabileceğimiz gibi ve konteynerlerin cluster yönetimi de bu sayede vSphere tarafından yapılır.

VCH Endpoint VM: vApp veya resource pool içerisinde çalışan bir sanal sunucudur ve her bir VCH için bir tane yaratılır. Temel görevi, docker remote API noktası olmasıdır. Kendisine gelen docker API komutlarını vSphere API komutlarına çevirir ve bu sayede konteynerlerin yaşam döngülerinin yönetilmesini sağlar. Kendi üzerinde konteyner barındırmaz. Üzerinde Port Layer adı verilen özel bir katman barındırır ve aslında bütün sihiri bu katman gerçekleştirir. VIC ortamına docker kimliğini kazandıran da bu port layer katmanıdır. Daha teknik açıdan baktığımızda, docker’ın libcontainer katmanına benzer bir görev yapar, dolayısı ile ileride farklı kimliklerin de desteklenmesini bekleyebiliriz.

Container VMs: VIC-engine tarafından oluşturulmuş ve içerisinde sadece tek bir konteyner çalıştıran, işletim sistemi PhotonOS olan minimal sanal sunuculardır. İndirdiğimiz VIC klasörü içerisinde yer alan bootstrap.iso ile PhotonOS’in mini versiyonu başlatılır, üzerine ilgili docker imajı gönderilir ve konteyner bu imajdan ayağa kaldırılır. Tüm bu işlem birkaç saniye içerisinde tamamlanır.

vic1

VCH kurulumunu gerçekleştirmek için, My VMware üzerinden paketi indirip, uygun bir sistem üzerinde açmamız gerekir. Bu paketin içeriği aşağıdaki gibi olacaktır.


root@demophoton [ ~/vic ]# ls -lh
total 377M
-rw-r----- 1 root root 205K Dec 3 19:29 LICENSE
-rw-r----- 1 root root 57 Dec 3 19:29 README
drwxr-x--- 2 root root 4.0K Dec 29 11:37 VCH01
-rw-r----- 1 root root 122M Dec 3 19:30 appliance.iso
-rw-r----- 1 root root 63M Dec 3 19:30 bootstrap.iso
drwxr-x--- 5 root root 4.0K Dec 28 12:33 ui
-rw-r----- 1 root root 34M Dec 3 19:29 vic-machine-darwin
-rwxr-x--- 1 root root 34M Dec 3 19:29 vic-machine-linux
-rw-r----- 1 root root 34M Dec 3 19:29 vic-machine-windows.exe
-rw-r----- 1 root root 35K Jan 6 07:37 vic-machine.log
-rw-r----- 1 root root 31M Dec 3 19:29 vic-ui-darwin
-rwxr-x--- 1 root root 31M Dec 3 19:29 vic-ui-linux
-rw-r----- 1 root root 31M Dec 3 19:29 vic-ui-windows.exe

Burada farklı işletim sistemleri için kullanılması gereken çalıştırılabilir dosyaları görebiliriz. Ben vic-machine olarak PhotonOS tercih ettiğimden dolayı, linux etiketli komutları kullanacağım. Bu komut ile birlikte VCH yaratma, silme, listeleme, inceleme gibi işlemleri yapabiliriz.

Bir VCH yaratmak istediğimizde, VIC’in yapacağı şey bir vApp ve bu vApp içerisine VCH Endpoint VM oluşturmak olacaktır. Yukarıdaki dosyalar arasında yer alan appliance.iso VCH VM’i, bootstrap.iso ise konteyner sanal sunucularını ayağa kaldırmak için kullanılır.

Bir VCH yaratabilmek için, vic-machine-linux komutunu, çok fazla parametre ile birlikte çalıştırmamız gerekiyor. Bu parametre setleri içerisinde vSphere tanımları, güvenlik, network, disk, özel registry, ip havuzları, kaynak yönetimi gibi bir çok kategoride parametre bulunmaktadır. Parametrelerin tüm listesine buradan erişebilirsiniz. Kendi ortamımda örnek olarak kullandığım komut seti aşağıdaki gibi oldu;


./vic-machine-linux create \
--name=demovch01 \
--target=demovc.demo.local/DEMO.Datacenter \
--thumbprint="E6:C9:E2:6E:90:9D:DB:5B:48:AA:F6:F6:0E:5D:16:16:4E:52:32:D7" \
--user=orcunuso \
--compute-resource=DEMO.Cluster/DEMO.Vic \
--image-store=datastore1/demovch01 \
--volume-store=datastore1/demovch01:default \
--bridge-network=DPG.Vlan200 \
--public-network=DPG.Vlan100 \
--client-network=DPG.Vlan100 \
--management-network=DPG.Vlan100 \
--dns-server=10.1.94.10 \
--public-network-ip=10.1.93.24 \
--public-network-gateway=10.1.93.1/24 \
--bridge-network-range=172.16.0.0/12 \
--no-tls \
--registry-ca=/root/vic/ca.crt \
--appliance-cpu=2 \
--appliance-memory=4096

VCH kurulumu aşamasında karşılaşabileceğimiz hatalar:

  • İlk denemede 4 numaralı satırda yazılan, vCenter sunucusunun SSL sertifikasının parmak izini bilemiyor olabiliriz. Bunu öğrenmek için ilk komutu –thumbprint olmadan çalıştırıp, alınan hata içerisinden parmak izini öğrenebiliriz.
  • İlgili ESXi sunucularında dışarıya doğru TCP/2377 portunun açık olması gerekmektedir. Eğer değilse, kurulum devam etmeyecektir.

Kurulum parametrelerinde bir hatamız yok ise, uzun bir çıktı sonrasında VCH’ımız hazır hale gelecektir.

vic2

Burada bize 3 konuda nasihat vermiş görünüyor. Birincisi, VCH operasyonları için kurulumu yaptığımız kullanıcının haricinde bir kullanıcı oluşturmamızı ve –ops-user parametresi ile belirtmemiz gerektiğini söylüyor. İkincisi, –no-tls parametremize kızıyor ve güvensiz bağlantılar konusunda uyarıyor. Üçüncüsünde ise, konteyner ve volume’lerin barınacağı diskin paylaşımlı olmadığını ve diğer ESXi sunucuların erişemeyeceğini söylüyor. Bence üçünde de son derece haklı :))

vCenter tarafından da kontrol ettiğimizde, seçtiğimiz küme ve resource pool içerisinde bir adet vApp ve endpoint görevi görecek bir adet VM oluşturulduğunu görebiliriz.

vic3

Bir sonraki yazıda ise VCH üzerinde temel docker operasyonlarını nasıl yapabileceğimizi göreceğiz.

 

Kategoriler:VMware Etiketler:,
%d blogcu bunu beğendi: