Vmware Workstation İçinde Vmware ESXi Lab #4

Tekrar merhaba. Yazının bu son bölümünde, önceki bölümlerde eksik kalan veya içime sinmeyen bazı yerleri değiştirip deyim yerindeyse "Bu altyapıyı ben kursam ne yapardım?" sorusunun yanıtını vermeye çalışacağım. Bunun için öncelikle bütün Windows'ları çöpe atacak ve servisleri linux'ta kuracağım. Dolayısıyla altyapı tamamen değişecek (bkz: tesisatın komple değişmesi lazım).

Önceki bölümler şu şekildeydi:
1. Bölüm: ESXi Hostların ve Windows Şablonunun Kurulumu
2. Bölüm: DC ve vCenter Kurulumu. Datacenter, Cluster ve Host Eklemek
3. Bölüm: Disk ve Ağların Eklenmesi. Sanal makinalar, Migration, Fault Tolerance
4. Bölüm: Altyapının Linux'ta Kurulması, vCenter Appliance Kurulumu ve Ayarları

Altyapının Linux'ta Yeniden Kurulması

Altyapının fazlasıyla Windows bağımlı olması baştan beri hoşuma gitmiyordu. Radikal bir hareketle DC ve vCenter makinalarını kapattım. iSCSI servisi vCenter makinasında çalıştığından artık disklere ulaşılamayacak. Bu nedenle ESXi hostları da kaynak harcamaması için kapattım. Linux, iSCSI'yi zaten destekliyor. DNS kurmak da oldukça kolay. vSphere, linux'a kurulamıyor ama onu da Virtual Appliance olarak çalıştıracağım. Virtual Appliance (.ova dosyaları), paketlenmiş ve taşınabilir (portable) olması hedeflenmiş sanal makina dosyalarıdır. Teoride, bir ova dosyası (ova: Open Virtual Appliance) HyperV, VirtualBox, VMware ve RHV tarafından kullanılabilir. Pratikte dosya, çalıştırılmak istenen platformların desteklemediği bir özellik içeriyorsa hata alır. Örn. VMware'de oluşturulan bir ova, HyperV'de desteklenmeyen bir özellik içeriyorsa, HyperV ben bunu içeri aktaramam (import) diyip işin içinden çıkar.

Her sanallaştırma altyapısında iki önemli bileşen vardır. Biri disk dosyası, diğeri de sanal makina dosyası. Vmware için bunlar sırayla vmdk ve vmx dosyalardır. Ova ise aslında bir tar dosyasıdır ve içinde temelde vmdk disk dosyası (veya dosyaları) ve xml biçimli bir ovf dosya bulundurur. Ovf'nin içinde sanal makinanın RAM, işlemci, denetleyici vb. özellikleri ve kullanacağı disk dosyasının adı bulunur. Ova dosya tar gibi açılır, içindeki xml'e uygun bir sanal makina elle oluşturulup disk olarak da ova'dan çıkan vmdk sanal makinaya eklenirse ova'nın aktarımı yapılmış olur. Vmdk dosya başka biçimlere dönüştürülürse farklı platformlara da aynı yöntemle aktarılabilir. Benzer şekilde, desteklenmeyen bir özelliğinden dolayı hata alan ova dosyasının xml'inden desteklenmeyen özellik çıkarılırsa büyük olasılıkla makina çalışacaktır. Bazı ova dosyalarda, ova içindeki dosyaların hash'lerini tutan bir dosya daha vardır. Eğer ova dosyadaki bir dosya değiştirilecekse, hash dosyası da silinmeli veya düzenlenmelidir. 

vCenter 5.5'in ova dosyasını indirdim. Dosyanın tam adı VMware-vCenter-Server-Appliance-5.5.0.30000-3000347_OVF10.ova. Örnek olması açısından dosya adının sonuna .tar ekleyip WinRAR ile açtım (sağda). Sanal makinada iki disk olduğundan iki vmdk dosya var. .mf uzantılı dosya, yukarıda da bahsettiğim manifest dosyası, disklerin ve ovf dosyanın SHA1 hash'lerini tutuyor. .cert dosya ova dosyasının vmware tarafından imzalanmış sertifikası. Görüntüde, ovf dosya metin düzenleyiciyle açıldığında içinde vmdk dosyalara ve bir ağ kartına referanslar görünüyor.

Bu virt. appliance'a geri döneceğim ama önce bir linux makina kurmalıyım. Bunun için VMware Workstation'ı açtım. File -> New Virtual Machine'i seçtim. Kurulum türü "Custom" seçip, "I will install the operating system later."ı işaretledim. "Guest Operating System" Linux ve sürüm "RedHat Enterprise Linux 6 64-bit" seçtim. Sanal makinaya "sierra" adını verdim. Bir çekirdek ve 2 GB RAM yeterli. "Do not use a network connection"ı işaretleyip ağ kartlarını ayarlamayı sonraya bıraktım. 20 GB'lik yeni bir disk oluşturup tek dosyada saklanacak şekilde ayarladım ve sihirbazı tamamladım. Sonra sanal makina özelliklerini açıp üç ağ kartı ekledim. İlki "Custom: VMnet2" ikincisi "Custom: VMnet3" ve sonuncusu NAT. NAT, kurulacak paketlerin indirilmesi ve DNS sorgularının iletilmesi için gerekli. Minimal kalıp dosyası yerine DVD indirilirse paketler için NAT'a gerek kalmaz. Ben yine de NAT'lı bir konfigürasyon kurdum. Ses kartı ve yazıcı gibi gereksiz parçaları çıkardım, CD sürücüye Centos 6.9 x86_64 minimal kalıp dosyasını taktım. DVD'den kurulumda, kurulum türü minimal seçilmeli. Makinanın son hali aşağıdaki gibi.

Makinayı başlattım. Hostname olarak "sierra.lab.local" verdim. IP'leri makina açıldıktan sonra ayarlayacağım. Kurulumda disk bölümlendirilirken swap'e bir bölüm ve kök dizine bir bölüm ayrılıyor. Bu üretim ortamında tavsiye edilmez, en azından /home, /var ve /tmp'in ayrılması önerilir ama ben hızlıca kurup geçtim. Kurulum bitince makinayı yeniden başlattım. Konsolda ifconfig -a çıktısından kontrol ettiğimde kartlar benim eklediğim sırada listelendi (MAC adreslerinden kontrol ettim). eth0 - vmnet2'ye, eth1 - vmnet3'e ve eth2 NAT'a bağlı. /etc/sysconfig/network-scripts/ifcfg-eth2 dosyasını açtım ONBOOT=no olan satırı ONBOOT=yes yapıp dosyayı kaydettim. vi yerine sed -i -e 's/T=no/T=yes/' /etc/sysconfig/network-scripts/ifcfg-eth2 komutu da kullanılabilir. service network restart ve tekrar ifconfig sonrasında sanal makina NAT'ın DHCP'sinden bir IP aldı. Fiziksel makinamdaki putty'den bu IP'ye SSH yapıp kuruluma putty ile devam ettim.

/etc/sysconfig/network-scripts/ifcfg-eth0 dosyasını aşağıdaki gibi düzenledim:

DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=10.10.2.3
NETMASK=255.255.255.0

eth0, DNS için kullanılacak, bir de iptables'dan NAT yönlendirmesi yapılacak. Bu yüzden eski DNS sunucunun IP'sini buna verdim. Benzer şekilde /etc/sysconfig/network-scripts/ifcfg-eth1 dosyasının içeriğini şöyle düzenledim:

DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=10.10.3.1
NETMASK=255.255.255.0

eth1, iSCSI için kullanılacak. Bu yüzden eski vCenter makinasının iSCSI IP'sini eth1'e verdim ve service network restart komutunu çalıştırınca arabirimlerin IP'leri atandı.

/etc/resolv.conf'un içeriği aşağıdaki gibi:

; generated by /sbin/dhclient-script
search localdomain lab.local
nameserver 192.168.220.2

resolv.conf, network servisi her yeniden başlatıldığında otomatik oluşturulan bir dosya. İçeriği, DHCP'den IP'sini alan arabirimin betikleri tarafından oluşturuluyor. Bundan iki paragraf sonra bahsedeceğim. nameserver'ın değeri her makinada farklı olmalı, özellikle üçüncü oktet. Ve bu dosyadan şu anlaşılmalı: kullanılan NAT ağı 192.168.220.0/24 ve bu ağdaki DNS sunucu 192.168.220.2, kendi IP'mi daha önce ipconfig çıktısından bulmuştum (192.168.220.133). DNS kurulduktan sonra makina kendi sorgularına da yanıt verecek. 

Önce yum -y install bind bind-utils komutuyla DNS servisini kurdum. Bir DNS servisi için 10 MB kabul edilebilir bir büyüklük. /etc/named.conf dosyasını açtım. Sierra sunucusu kendi DNS sorgularına kendi yanıt verecekse ayarlar şöyle olmalı (bunlar yalnızca değişmesi gereken ifadeler, forwarders ifadesi options içine eklenecek):

listen-on port 53 { 10.10.2.3; 192.168.220.133; };
allow-query       { 10.10.2.0/24; 192.168.220.133; };
forwarders        { 192.168.220.2; };
dnssec-enable no;
dnssec-validation no;

ve resolv.conf'un içeriği

search lab.local
nameserver 192.168.220.133

olmalı. Ancak bu dosyada bir değişiklik yapmadım. resolv.conf'taki değişiklikleri kalıcı olarak yansıtabilmek için /etc/sysconfig/network-scripts/ifcfg-eth2 dosyasının sonuna

DNS1=192.168.220.133
SEARCH=lab.local

ifadesini ekledim. DNS1 değeri nameserver'a, SEARCH değeri de search ifadesine aktarılıyor. Bu arada named.conf içindeki listen-on-v6 ifadesini, ipv6 kullanılmayacağından başına '//' eklenerek kapattım. network servisini yeniden başlattım, resolv.conf'daki değişiklikler dhclient betikleri tarafından uygulandı. Eğer sunucu DNS sorgularını NAT'ın DNS'ine soracaksa, ifcfg-eth2'de DNS1 ile başlayan satırın girilmesine gerek yok. Aynı zamanda named.conf'ta da "listen-on" ve "allow-query" ifadelerinden sunucunun kendi IP'si çıkarılmalı. Ben ilk konfigürasyonu tercih ettim, herhangi bir nedeni veya üstünlüğü yok.

Sonrasında, named.conf'ta içerilen /etc/named.rfc1912.zones dosyasına aşağıdaki satırları ekleyerek düz ve ters DNS zonları için iki dosya belirttim: 

zone "lab.local" IN {
   type master;
   file "/var/named/lab.local.zone";
   allow-update { none; };
};

zone "2.10.10.in-addr.arpa" IN {
   type master;
   file "/var/named/2.10.10.reverse";
   allow-update { none; };
};

Yukarıdakiler zon tanımları. Zonların içeriği belirttiğim dosyalarda olacak. /var/named/lab.local.zone dosyası aşağıdaki gibi:

$TTL 86400
@  IN  SOA  sierra.lab.local.  sierra.lab.local. (
            2018011701 ; serial
            21600      ; refresh after 6 hours
            3600       ; retry after 1 hour
            604800     ; expire after 1 week
            86400 )    ; minimum TTL of 1 day

    IN  NS  sierra.lab.local.
    IN  MX  10  sierra.lab.local.

esxi5-01  IN  A    10.10.2.1
esxi5-02  IN  A    10.10.2.2
sierra    IN  A    10.10.2.3
vcenter   IN  A    10.10.2.4

/var/named/2.10.10.reverse dosyası da şöyle:

$TTL 86400
@  IN  SOA  sierra.lab.local.  sierra.lab.local. (
            2018011701 ; serial
            21600      ; refresh after 6 hours
            3600       ; retry after 1 hour
            604800     ; expire after 1 week
            86400 )    ; minimum TTL of 1 day

    IN  NS  sierra.lab.local.

1   IN   PTR   esxi5-01.lab.local.
2   IN   PTR   esxi5-02.lab.local.
3   IN   PTR   sierra.lab.local.
4   IN   PTR   vcenter.lab.local.

Son olarak DNS'e iptables'da izin vermek için şu iki komutu çalıştırdım.

iptables -I INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
iptables -I INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT

Ve elbette service iptables save komutuyla kuralları kaydettim. Sonra service named start ile DNS sunucuyu başlattım ve chkconfig named on komutuyla başlangıçta açılmasını sağladım. Denemek için nslookup esxi5-01 komutunu çalıştırdığımda doğru IP kaydı döndü. 

Bir konu özellikle dikkat çekici. İlk yazıda oluşturduğum şablon 6.92 GB'ydi. Buna ek olarak DC 581 MB, vCenter 18 GB'dı (10 GB'ı thick provision disk). Bu arada hile yapmıyorum, bu büyüklükler sanal makinaların diskleri "clean-up" yapıldıktan sonraki değerler ve makinalar kapalı. Yani RAM disk hariç. Bir DNS ve LDAP servisi için 581 MB alan hiç mantıklı değil. Oysa, sierra makinasına baktığımda işletim sistemi ve DNS, toplam 693 MB.

Depolama servisleri oluşturulmadan önce makinaya iki disk eklenmeli. Büyüklük olarak 15 GB yeterli, thin veya thick olması önemli değil. Eğer diskte yer varsa thick olabilir. Bunlar datastore olacağından thick olması performans sağlayacaktır. Ben yer kazanmak için thin olarak ekledim. Diskler eklendiğinde linux diskleri algılamadı. fdisk -l yeni diskleri listeleyemedi. Aşağıdaki betiği çalıştırdım:

for HOST in /sys/class/scsi_host/*; do echo "- - -" \
> $HOST/scan ; echo $HOST/scan; done

Tekrar fdisk -l ile baktığımda /dev/sdb ve /dev/sdc olmak üzere iki disk bulundu. /dev/sdb diskini NFS datastore için ekledim. NFS'i ayarlamak kolay. Fakat NFS'te fiziksel disk paylaştırılamıyor yalnızca dizin paylaştırılabiliyor. Bu nedenle dosya sistemi oluşturulmalı. Önce diskte bir bölüm oluşturdum:

echo -ne "n\np\n1\n\n\nw\nq\n" | fdisk /dev/sdb

fdisk komutlarıyla tek tek uğraşmamak için komutları echo ile verdim. Merak eden okuyucu komutları elle tek tek girebilir. Diski ext4'le biçimlendirip bir "mount point" oluşturdum:

mkfs.ext4 /dev/sdb1
mkdir /NFSexport

/etc/fstab dosyasının sonuna şu satırı ekledim:

/dev/sdb1    /NFSexport    ext4    defaults    0 0

ve diski mount -a komutuyla bağladım. Komutun herhangi bir hata almaması ve df -hP komutunun çıktısında şu satırın bulunması gerek:

/dev/sdb1    15G   38M   14G   1% /NFSexport

Sonra NFS paketlerini yükledim:

yum install nfs-utils nfs-utils-lib

/etc/exports dosyasına aşağıdaki satırı ekledim:

/NFSexport 10.10.3.0/24(rw,no_root_squash,sync)

Son olarak servisi başlatıp, açılışta da başlayacak şekilde ayarladım:

chkconfig nfs on
service rpcbind start
service nfs start

Herşey düzgün çalıştıysa showmount -e 10.10.3.1 komutunun çıktısında export edilen kaynak görünüyor olmalı. Ancak bununla bitmedi, aşağıdaki komutlarla* NFS portlarını iptables'dan da açtım (birinci komuta dikkat, yazının sonundaki önemli nota bakınız):

iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp -m tcp --dport 49356 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p udp --dport 111 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp --dport 111 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp --dport 2049 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp --dport 32803 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p udp --dport 32769 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp --dport 892 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p udp --dport 892 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp --dport 875 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p udp --dport 875 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p tcp --dport 662 -j ACCEPT
iptables -I INPUT -s 10.10.3.0/24 -m state --state NEW \
-p udp --dport 662 -j ACCEPT

Kalıcı olmaları için tekrar service iptables save komutunu çalıştırdım. NFS kurulumu bu kadar.

Sıra iSCSI servisine geldi. Bunun ayarları için internetteki en iyi kaynaktan yararlandım. Kaynakta komutların açıklamaları var bu nedenle aşağıda yalnız komutları yazdım:

yum -y install scsi-target-utils
iptables -I INPUT -p tcp -m tcp --dport 3260 -j ACCEPT
service iptables save
service tgtd start
chkconfig tgtd on

echo -ne "n\np\n1\n\n\nw\nq\n" | fdisk /dev/sdc

/etc/tgt/targets.conf dosyasında "default-driver iscsi" ifadesinin hemen altına aşağıdaki satırları ekledim:

<target iqn.2018-01.local.lab.sierra:target1>
        backing-store /dev/sdc1
        initiator-address 10.10.3.0/24
</target>

ve service tgtd restart komutuyla servisi yeniden başlattım. tgt-admin --show komutuyla eklediğim kaynağı kontrol ettim. Kurulumun hepsi bu ama eksik olduğunu düşündüğüm bir konu daha var. İlk bölümde ESXi hostların def. gw.'leri DC makinası olarak verilmişti. Normalde makinalar internete çıkmadıklarından bunun önemi yok ama internete çıkmayan bir makinanın da def. gw.'i olması anlamsız. O halde makinalar sierra üzerinden NAT'la internete çıksın. Normalde böyle bir kurulumda iptables servisini kapatırdım ama baştan beri NAT kurmayı planladığımdan açık bıraktım.

NAT aşağıdaki dört komutla yapılır*:

iptables -I FORWARD -i eth0 -j ACCEPT
iptables -I FORWARD -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables kurallarının kalıcı olması için service iptables save komutunu verdim ve IP forwarding'in açık olması için /etc/sysctl.conf içerisinde net.ipv4.ip_forward değerini 1 olarak değiştirdim ( sed -i -e 's/ip_forward = 0/ip_forward = 1/' /etc/sysctl.conf ).

Bunu da tamamladığıma göre altyapı tamamen hazır. O halde vCenter kuruluma geçebilirim.


vCenter Server Appliance Kurulumu ve Ayarları

Vmware Workstation'da, File -> Open'dan ova dosyasını açtım. Dosyanın adı VMware-vCenter-Server-Appliance-5.5.0.30000-3000347_OVF10 .ova. Eski vCenter makinasını silmediğim için buna "vCenterAppliance" adını verdim. Import'a bastığımda vmdk dosya sanal makinanın dizinine kopyalandı, xml dosya vmx'e dönüştürüldü. Makinanın özelliklerini kendi ortamım için biraz değiştirdim. Öncelikle 8 GB bellek fazla. Önceki vCenter gibi 4 GB'a indirdim, aslında 2 GB bile yeterli. Ağ kartı "Bridged" olarak geliyor. Bunu "Host-only" yaptım ve bir kart daha ekleyip bunu da Vmnet2'ye bağladım. Son durumda donanım aşağıdaki gibi olması gerek. Sonrasında makinayı açtım.

Host-only ağında da DHCP bulunduğundan kendiliğinden bir IP aldı. Makina'nın konsolunda mavi bir ekranda bu IP yazıyor ve yapılması gerekenler anlatılıyor. Alt tarafta "Login" seçiliyken "Enter"a basıp komut satırına geçilebilir. Kullanıcı adı "root" ve parolası "vmware". Makina SuSe tabanlı olduğundan RedHat'e benziyor. Mümkün olduğu kadar komut satırından kaçınmaya çalıştım. (Eski) vCenter makinasının web arayüzüne girmek için sanal makinaya Chrome kurmuştum. Bu yapıda tarayıcı kurabileceğim makina olmadığından vCenter appliance'ın arayüzüne fiziksel makinamdaki tarayıcıyla ulaştım.

Önce konsolda yazdığı gibi https://192.168.189.130:5480/ adresine gittim. Aldığım sertifika hatasını geçip sonraki ekranda kullanıcı adı "root", şifre "vmware" girdim ve kuruluma başladım. Lisans anlaşmasını kabul edip "Next"e basar basmaz Vmware ile ilgili servislerin başladığı konsolda görülebilir. Geçici bir kurulum olduğundan veri toplanmasını kabul etmeden "Next"e bastım, "Configure with default settings"i seçip tekrar "Next" bastım ve son adımda "Start"a basıp otomatik ayarlarla vCenter'in kurulumunu başlattım. "Configuring SSO" adımı uzun sürebilir. Beş madde tamamlanıp kurulum bitince "Close"a bastım. Kurulum neredeyse bitti. Appliance'ın en güzel yanı hemen hemen hiçbir ayar gerektirmemesi. "SSO" altsekmesinde administrator@vsphere.local kullanıcısının şifresi ayarlanabiliyor. Normalde şifre "vmware".

Asıl önemli ayarlar "Network" sekmesinin "Address" alt sekmesinde. "Failed to read network interface (eth1) information" hatası alınması normal çünkü henüz bir ifcfg-eth1 dosyası oluşmadı ve ne yazık ki sihirbaz bu dosyayı kendiliğinden oluşturamıyor. Bu nedenle konsola gidip touch /etc/sysconfig/network/ifcfg-eth1 komutuyla boş bir dosya oluşturdum ve web arayüzüne geri döndüm. Altsekmeye geçtikten sonra hem "eth0"a hem de "eth1"e ait "IPv4 Address Type"ı DHCP'den "Static"e çektim. Tüm ayarlar yukarıdaki gibi olmalı. "Preferred DNS Server"daki IP'yi "Alternate DNS Server"a kaydırdım. Otomatik alınan IP adresini de eth0'a elle verdim. Bu IP'ler de (özellikle üçüncü oktet) her makinada farklı olacak.

"Save Settings"e basıp ayarları kaydettim. Konsola geri dönüp oluşturduğum boş dosyaya baktığımda girdiğim ayarları gördüm. Def. GW de düzgün ayarlanmış ve bu makina sierra üzerinden internete çıkıyor. Hazır konsol açıkken /etc/resolv.conf'a "search lab.local" ifadesini ekledim. Tekrar web arayüzüne dönüp "vCenter Server" altında "Time" sekmesini açtım, "NTP synchronization"ı seçip http://www.pool.ntp.org/zone/tr adresindeki NTP sunucuları virgülle ayırarak "NTP Servers" bölümüne yazdım ve "Save Settings"e basarak kaydettim.

vCenter kurulumu bu kadar ama IP ayarları özellikle Def. GW değiştiği için yapılması gereken birşey daha var. Server Appliance yönetim ekranında "Admin" sekmesine geçtim, "Certificate regeneration enabled: Yes" olarak işaretleyip "Submit"e bastım, sonra da "System" sekmesinden "Reboot"a bastım. Bu yapılmazsa bir sonraki yeniden başlatmada web istemcisi sertifika uyuşmazlığından SSO servisine bağlanamıyor. Böyle bir durumda şu hata alınıyor: Failed to connect to VMware Lookup Service https://[hostname]:7444/lookupservice/sdk – SSL certificate verification failed (Kaynak)

Makina açıldıktan sonra https://192.168.189.130/ adresinden web istemcisine ulaştım. Bu arada sunucu hemen kendine gelemiyor, biraz bekleyip tekrar denemek gerekebilir. Web istemcisi açılınca administrator@vsphere.local ile vCenter'a girdim. Bu arada bir yandan ESXi hostları da açtım. Onları vCenter'a eklemeye sıra gelene kadar açılmış olacaklar.

Bundan sonraki işler ilk vCenter ile aynı, sadece arayüz farklı. "DataCenter" oluşturmak için vCenter'a ve sonra "Hosts and Clusters"a basınca dört adımlı bir sihirbaz çıktı. "localhost"a sağ tıklayıp "New Datacenter"a bastım ve "DC-Lab" diye bir "Datacenter" oluşturdum. Ardından, yeni "Datacenter"a sağ tıklayıp "New Cluster..."ı seçtim, "Prod" adında bir "cluster" oluşturdum. DRS ve "vSphere HA" gibi özellikleri daha önce anlatmıştım. İhtiyaca göre açılabilir. Bundan sonra "Add a host"a bastım. "Host name" olarak "esxi5-01.lab.local" yazıp "Next"e bastım. Sonraki adımda ESXi'nin kullanıcı adı ve şifresini girip "Next"e basınca hostun parmak izi geldi, bunu "Yes" diyip geçtim. Parmak iziyle ilgili mesaj gelmiyorsa önce ESXi hostun açılıp açılmadığına ve açıksa vcenter appliance konsolundan ping çıktısına bakmak gerekir. Sonraki adımları "Next" diyip geçtim ve ilk hostu ekledim. Aynı şekilde ikinci makinayı da ekledim. Web istemcisinde "Unknown (inaccessible)" adlı sanal makinalar çıktı. Bunlara sağ tıkladım, "Remove from Inventory" diyip sildim. Bunlar eski CentOS makinaları (FT için oluşturduğum) ama eski datastore olmadığından kayıtlarına ulaşılamıyor.

ESXi hostların ilk kurulumunda DNS'e 10.10.2.4 IP'sini vermiştim ama bu kurulumda DNS'i 10.10.2.3'te ayağa kaldırdım. Hostun DNS'ini düzeltmek için konsoldan F2'ye iki kere basıp şifremi girdim. Çıkan menüde "Configure Management Network"ü seçtim ve sonraki adımda "DNS Configuration"a girdim. "Primary DNS Server" alanına 10.10.2.4 yerine 10.10.2.3 yazdım ve Enter'a basarak çıktım. Esc'e basıp "Test Management Network"ü seçince bütün denemeler sorunsuz tamamlandı.

Tarayıcıdaki vSphere'e geri döndüm. Eski vCenter'dan yapılan ağ ayarları hostlar üzerinde kayıtlı olduğu için burada onları tekrar yapmam gerekmedi. Hostlardan birine bastım (sağda 1), "Manage" sekmesinden (2) "Storage" alt sekmesini açtım (3). Altta "Storage Devices"a bastığımda (4) 15 GB'lik iSCSI diski listede gördüm (5). Diskin üstüne bastığımda diskin 2 ayrı "path"den (iki farklı vmnic'ten) geldiğini ve bu diski sunan makinanın iqn.2018-01.local.lab.sierra... olduğunu gördüm (6).

Diski eklemek için sol çerçevenin üstündeki disk simgesine (solda 1) bastım. Oradan DC-Lab "datacenter"ını seçtim (2), "Related Objects" sekmesine geçip (3) onun altında "Datastores"a bastım (4). Soldan ilk simgeye bastığımda (5) disk ekleme sihirbazı açıldı. "Next"e basarak devam ettim (6). Sonraki adımda "VMFS"i seçili bıraktım. Üçüncü adımda "Datastore name: sharedstorage" ve "Select a host to view..."da hostlardan birini seçtim. Altta 15 GB'lik disk listelendi. Onu seçip "Next"e bastım. Diğer tüm adımlarda da "Next"e basıp sihirbazı tamamladım ve disk eklendi. Bir disk daha eklemek için disk ekleme sihirbazını tekrar başlattım. Bu sefer ikinci adımda NFS seçip "Next"e bastım.

NFS ayarlarını yukarıdaki gibi yaptım. Datastore name: nfsdatastore, Server: 10.10.3.1, Folder: /NFSexport olarak girip sonra "Next"e bastım. Her iki sunucuyu da seçtim, tekrar "Next"e ve "Finish"e basıp NFS diski de ekledim.

Önemli Not: NFS servisi (özel olarak mountd), makina her yeniden başlatıldığında başka portları kullanır. mountd portları sierra makinasında rpcinfo -p localhost komutuyla listelenir ve vSphere'de NFS paylaşımına erişilemiyorsa iptables'da bu portlar açılır. Daha hızlı (ve güvensiz) çözüm portlar yerine hostların IP'lerine iptables kuralı yazılmasıdır:

iptables -I INPUT -s 10.10.3.11 -m state --state NEW \
-j ACCEPT
iptables -I INPUT -s 10.10.3.12 -m state --state NEW \
-j ACCEPT
iptables -I INPUT -s 10.10.3.21 -m state --state NEW \
-j ACCEPT
iptables -I INPUT -s 10.10.3.22 -m state --state NEW \
-j ACCEPT

veya ileride başka hostlar da ekleneceği gözönüne alınarak daha geniş bir kuralla o arabirimden gelen bütün paketler kabul edilebilir.

iptables -I INPUT -i eth1 -m state --state NEW -j ACCEPT

Yazının ortalarında 49356/tcp'yi açtığım iptables kuralı, makina yeniden başlatıldığında geçersiz olacak ve her defasında doğru portla değiştirilmesi gerekecektir. Bir başka çözüm, tek port tanımlamaktansa mountd servisinin port aralığına izin verilmesidir. 

Hem NFS hem iSCSI olmak üzere iki farklı datastore ekledim. Normalde NFS'in yüksek GÇ gerektiren işlerde kullanılması pek tavsiye edilmez. NFS, daha çok depolama ve sık erişim gerektirmeyen dosyaların saklanmasında kullanılır. Üretim ortamında bile yavaş kalacağı düşünülen bir sistemin lab ortamında da pek verimli olması beklenmemelidir. Üstelik de NFS'in altındaki diskler Thin provision olarak eklenmişse.

Son...

Bundan başka benim anlatacağım veya ekleyeceğim birşey kalmadı. Sanal makina kurulumunu daha önce yaptığım için burada değinmiyorum. FT özellikleri de benzer şekilde kurulup denenebilir.

Buraya kadar uzun ama benim için hayli eğitici olan bir yazı oldu, umarım okuyucular da benimle aynı fikri paylaşıyordur. Buraya kadar okuyan kaldıysa sabrına çok teşekkür ediyorum. Bundan sonraki yazıda yine daha düşük seviye konuları ele almak istiyorum. Bundan sonraki yazılarda C ve Fortran'daki iki matematik kütüphanesinden bahsedecek ve gcc'nin yaptığı derleme optimizasyonlarına değineceğim. 

Vmware Workstation İçinde Vmware ESXi Lab #3

Bir önceki yazıda hostları ekleyip vCenter'ı sanal makina oluşturulabilir duruma getirmiş ama sanal makina oluşturmamıştım. Sanal makinalarla çalışmaya başlamadan önce altyapıyı düzgün ve etkin çalışır duruma getirmek için yapılması gereken işler var. Birinci olarak iSCSI'yle paylaşımlı bir disk eklenmeli. Sonra FT (Fault Tolerance) ve diğer ağların ayarlanması gerekiyor. Sonra sanal makinaları kurup vCenter'daki bazı özellikleri göstereceğim.

Bölümlerin konu başlıkları şöyle:
1. Bölüm: ESXi Hostların ve Windows Şablonunun Kurulumu
2. Bölüm: DC ve vCenter Kurulumu. Datacenter, Cluster ve Host Eklemek
3. Bölüm: Disk ve Ağların Eklenmesi. Sanal makinalar, Migration, Fault Tolerance

4. Bölüm: Altyapının Linux'ta Kurulması, vCenter Appliance Kurulumu ve Ayarları

Disklerin Bağlanması ve Ayarlanması

vCenter makinası kurulurken NAT'a bağlı bir ağ kartı eklemiştim. Bu adımda internet gerekecek. Bu yüzden kartın bağlı olup olmadığını kontrol edip (Virt. machine settings -> Network Adapter 3 (NAT) -> Device Status) değilse "Connected"i işaretleyip bağlayın. Ve elbette fiziksel makinanın internete çıktığına emin olun.

Öncelikle vCenter makinasına Chrome kurdum (Mozilla da olur). İlk yazıda söz ettiğim ESXi web arayüzüne girmek için adres satırına https://esxi5-01.lab.local/ yazdım. Sertifika hatasını Advanced -> Proceed to ... 'ya basıp geçtim. ESXi hostta bulunan bir sayfa açıldı. Buradaki bağlantılardan vSphere istemcisi veya vCenter indirilebilir (vmware'in sayfasından) ve bağlı disklerin (datastore) içeriğine bakılabilir. İlk sanal makinayı oluşturduktan sonra bu konuya döneceğim.

Her iki ESXi hostun paylaşımlı bir disk görmesi gerek. Sanal makinayı başka bir hosta taşırken hedef host, sanal makinanın disk dosyalarını (vmdk), donanım özelliklerini tutan vmx dosyasını ve swap dosyasını göremiyorsa makinayı taşıyamaz. "Migration" özelliğini kullanmak için paylaşımlı disklerin taşıma yapılacak makinalarca görülmesi gerekir. Vmware, paylaşımlı disk olarak NFS, iSCSI ve Fibrechannel (FC) SAN'i destekler. NFS, üretim ortamlarında kullanmak için yavaş kalır. FC, yüksek performanslı bir çözümdür ama altyapı yatırımı gerektirir. Labda ele almak için FC emülasyonu yapan bir program bilmiyorum. iSCSI, mevcut ethernet altyapısı üzerinden (tercihen 10G) FC'ymiş gibi disk paylaşımına olanak sağlar ve fakirin FC'si olarak bilinir. Labda, iSCSI yazılımıyla diskler kolayca paylaştırılır. VMware Workstation'a yeni bir sanal makina eklememek için depolama sunucusu olarak vCenter makinasını ve iSCSI yazılımı olarak Starwind Virtual SAN'i kullandım. Bu yazılım, https://www.starwindsoftware.com/starwind-virtual-san adresinden indirilebilir. Yazılımın olumsuz yönü, indirmek için bir eposta adresi girilmesini istemesi. Bu epostayla, kurulum dosyalarını indirmek için bir bağlantı ve deneme lisansı gönderiliyor.

10 GB Thick provision disk

Dosyayı vcenter makinasına indirdim. Eğer kazara fiziksel makinaya indirdiyseniz; sanal makinayla fiziksel makina arası dosya paylaşımı için yöntemler var ama vcenter makinası internete bağlı olduğundan wetransfer kullanmak bence en pratiği.

vcenter makinasını kurarken iSCSI için bir arabirim ekleyip buna IP vermiştim. Bu adımda iSCSI'yle sunmak üzere bir disk ekleyeceğim. Makalede disk 10 GB "thick provision" olarak belirtilmiş. Eğer fiziksel makinanın diskinde yer sıkıntısı varsa "thin" olabilir ama labda sanal makina yavaş kurulacaktır. Yer sıkıntısı yoksa 10 GB ile sınırlı kalmadan disk eklenebilir.

Disk eklemek için sanal makinanın özelliklerinden; Add -> Hard Disk (Next) -> SCSI (Next) -> "Create a new virtual disk" (Next) adımlarını izledim. Seçtiğim ayarlar yukarıda görülüyor. Bu ekrandan sonra Next ve Finish'e basınca vmdk dosyayı diskte oluşturmaya başlayacak. 10 GB'lik bir dosya oluşturmak bir dakika kadar sürebilir. Eklenen yeni disk yanda "Preallocated" olarak görünüyor. Tamama basınca disk eklenecek. Bunun için makinayı kapatmaya gerek yok.

Starwind kurulumundan önce yapılması gereken birşey daha var: .Net Core runtime dosyalarının kurulumu. https://www.microsoft.com/net/downloads/windows adresinden "x64 Installer (.exe)"ye ait Runtime kurulumunu seçip (dotnet-runtime-2.0.4-win-x64.exe) kurdum. Starwind'ı kurmadan önce lisans anahtarını zip dosyasından çıkarttım. Kurulum dosyasının adı starwind-v8.exe. Bunu çalıştırınca standart bir windows uygulama kurulumu gerçekleşiyor (Next -> Anlaşmayı kabul et -> Kurulum dizinini seç -> bir takım Next'ler daha -> Finish). Lisans anahtarı adımında "Thank you, I do have a key already"i seçip anahtarı gösterdim. Kurulumun bundan sonrası biraz karışık. Sihirbaz önce bir dll'le ilgili uyarı verdi. Uyarıya tamam dedim ve kurulum devam etti. "Installing Microsoft .NET Core" adımında bir süre bekledi ve kurulamadığında dair hata verdi, "Back" ve tekrar "Next"e bastığımda ikinci denememde kuruldu. Diğer yandan başka bir kurulumda yalnız dll uyarısını verdi ama sorunsuz kuruldu. Kurulum sırasında NAT arabiriminde bazı hareketler vardı. Anladığım kadarıyla internetten bazı dosyaları indirmeye çalışıyor ama yavaşlıktan birinci denemede zaman aşımına uğruyor. İkinci denemede muhtemelen DNS cache'den dolayı bağlantı hızlanınca tekrar zaman aşımına uğramıyor. Kurulumu bitirip Starwind'ın yönetim konsolunu açtım.

Program açılırken "Storage pool is not configured!" uyarısıyla açılıyor. Bunu 'Yes' diyip geçtim. Ana ekranda 127.0.0.1 sunucusuna sağ tıklayıp "Remove Server"a bastım. Sonra yukarıdan "Add Server"a basıp 10.10.3.1 IP'li bir sunucu ekledim (yanda). Üstüne çift tıklayıp sunucuya bağlandım. Sunucuya bağlanınca bununla ilgili ayarlar görülüyor.

Starwind'de yeni target eklemek

Sağdaki "Add Target" bağlantısına bastım. "Target Alias" olarak "starwind" verdim (sağda). Target'a birden çok sunucunun bağlanabilmesi için (ESXi hostlar) "Allow multiple concurrent iSCSI connections" seçeneği işaretli olmalı. Next ve Create'a basıp bir "target" oluşturdum. Target, iSCSI terminolojisindeki sunucu olarak düşünülebilir.

Solda "starwind" target'ı aktifken sağda "Devices"ın yanında bulunan "Add Device" bağlantısına bastım. "Hard Disk Device" ve sonra "Physical Disk" seçtim. Çıkan pencerede "Device Address" bölümünde 2,0,1,0 olarak görünen ikinci diski seçmek gerekiyor. Next -> Next -> Create diyince 10 GB'lik bir disk 'target'a eklenmiş olacak. Makalede iSCSI olarak fiziksel disk verilmemiş. İkinci disk bölümlendirilip içindeki bir imaj dosyası verilmiş. Ben kendi yöntemimi daha pratik buluyorum.

vCenter'a dönüp, ESXi5-01 hostuna bastım (sağda 1). Sağ tarafta Configuration'ı seçtim (2). Hardware altında "Storage Adapters"a bastım (3) ve listede boş bir yere sağ tıklayıp "Add Software iSCSI Adapter" dedim (4).

Çıkan uyarıya tamam dedikten sonra bir "iSCSI Software Adapter" oluştu (genelde vmhba33). Buna sağ tıklayıp "Properties"e basınca gelen pencerede (aşağıda) "Dynamic Discovery"i seçtim (1) ve "Add"e bastım (2). iSCSI server olarak 10.10.3.1 (3) girip tamama (4) ve sonra "Close"a bastım (5).

vSphere'de depolama sunucusunun eklenmesi

iSCSI taraması

"Close"a basınca yandaki mesaj kutusu çıkacak. Buna hayır dedim çünkü henüz iSCSI için hangi kartları kullanacağını ayarlamadım. Sonra aynı işlemleri ESXi5-02'de tekrarladım ve ilk hosta geri döndüm. Şimdi iSCSI için kullanılacak ağ kartlarını ayarlamam gerek.

Önce hostun "Configuration" sekmesine (yukarıda 1) gidip "Networking"i seçtim (2). "Add Networking"e basıp (3) "VMkernel"i seçtim (4) ve Next'e bastım. ESXi hostlardaki vmnic2 ve vmnic3 iSCSI için ayrılmıştı, bu nedenle her ikisini de seçtim (sağda). Bunu yapmakla her iki kartı birleştirerek kullanıyorum. 

Next'e basıp "Network Label"a iSCSI1 verdim (yukarıda). Tekrar "Next"e bastım.

Bu Vmkernel arabirimine 10.10.3.11 IP'sini ve 255.255.255.0 ağ maskesini atadım (yukarıda). Tamama bastığımda vSwitch1 içerisinde iSCSI1 portu oluştu. Aynı adımları uygulayıp bir VMkernel daha ekledim ama ağ kartı olarak daha önce vSwitch1'de grupladığım vmnic'leri kullandım. Bu yüzden ikinci adımda "Use vSwitch1"i seçtim. "Network Label" iSCSI2, IP: 10.10.3.12 ve ağ maskesi 255.255.255.0 atadım. Bu tamamlandığında sağ üstteki gibi görünmeli. Bundan sonraki adımda kartların önceliklerini ayarlamak için vSwitch1'in yanındaki "Properties"e bastım (sağ üst).

İlk çıkan pencerede iSCSI1'e çift tıkladım (sağda 1). Açılan pencerede "NIC Teaming" sekmesine gidip (2) "Override switch failover order"ı işaretledim (3). Sonra vmnic3'ü seçip (4) "Move Down"a basarak "Unused Adapters" bölümüne indirdim (5) ve tamama bastım. Aynısını iSCSI2 için de tekrarladım ama bu kez vmnic3'ü değil vmnic2'yi "Unused Adapters" bölümüne gönderdim (solda). Kapata basıp çıktım.

"Configuration" sekmesinde "Storage Adapters"a geri dönüp vmhba33'e sağ tıkladım ve "Properties"i seçtim. "Network Configuration" sekmesinde (sağda 1) "Add"e basıp (2) çıkan pencerede iSCSI1'i seçtim (3) ve tamama bastım (4). Sonra aynı şekilde "Add"a basıp iSCSI2'yi de ekledim, kapata bastım. "iSCSI taraması" altbaşlıklı görseldeki mesaj kutusu çıktı. Artık kartlar eklendiğinden evete bastım. vCenter makinasında oluşturulan target bulundu. Bu adımda target bulunamıyorsa ESXi'nin firewall'undan iSCSI portlarını açmak gerekebilir (bende gerekmedi). "Configuration" sekmesinin alt bölümündeki "Software" listesinden "Security Profile"a (aşağıda 1) basınca, servislerin ve firewall kurallarının yönetildiği ekran gelir. Portları açmak için firewall bölümünde "Properties"e basıp, listede "Software iSCSI Client"ı (2) seçmek ve tamama basmak yeterli. Bu tüm hostlarda yapılmalı.

Firewall'dan iSCSI portlarının açılması

Paylaşılan diski görmek için "vmhba33"e basınca, altta "Details"in altında (bölümlerin boyutlarını biraz kaydırmak gerekebilir) 10 GB'lik bir VMware iSCSI disk görülüyor ve host bu diski iki path'den görüyor. Bu şu demek; path'lerden biri vmnic2'den diğeri vmnic3'ten geliyor.

Aynı anda Starwind yönetim konsoluna gittiğimde ('system tray'deki mavi ikona çift tıklayınca açılan) bu target'a oturum açan initiator'lar* da göründü.

* Initator: iSCSI terminolojisinde istemciye ve iqn ile başlayan tanımlara verilen isimdir. iSCSI dünyasındaki MAC adresi gibi düşünülebilir. FC dünyasında buna karşılık WWN/WWP'lerden oluşan WWID'ler bulunur (sırasıyla world wide node (name), world wide port (name), world wide ID).

VMkernel arabirimlerinin eklenmesi ve kartların önceliklendirilmesini ikinci ESXi host için de tekrarlamak gerekiyor. Özet prosedür:

- ESXi05-02 -> Configuration -> Networking -> Add VMkernel (iki kere)

Not: İkinci hostta iSCSI1 için 10.10.3.21/255.255.255.0 ve iSCSI2 için 10.10.3.22/255.255.255.0 kullanılacak.

- vSwitch1 Properties -> (iSCSI1 -> NIC Teaming -> vmnic3 unused) + (iSCSI2 -> NIC Teaming -> vmnic2 unused)

- Storage Adapters -> vmhba33 Properties -> Network Conf. -> Add iSCSI1 + Add iSCSI2

Starwind yönetim konsolunda "target"ı gören iki "initiator" daha gelmiş olmalı.

Makinaları diski görecek şekilde ayarladım ama "datastore" olarak vCenter'a eklemedim. Bunun için herhangi bir hostun "Configuration" sekmesine geçtim. "Hardware" altında "Storage"a basıp önce "Rescan All"a bastım (yukarıda). Bu senaryoda "Rescan all" gerekli değil çünkü kartlar eklenince tarama yapıldı ve disk bulundu. Ben alışkanlık olarak bu işlemi her disk eklemeden önce yapıyorum. Sonra "Add Storage..."a bastım (yanda 1). Disk ekleme sihirbazı gayet kolay. Birden fazla disk eklenmeyecekse yalnızca diske bir ad vererek tamamlanıyor. "Next"e bastıktan sonra "Disk/LUN"u seçtim, tarama sonucu bulunan diskler listelendi. Zaten tek disk var, onu seçtim. Sonraki adımda disk formatını VMFS-5 olarak bıraktım. Diske "sharedstorage" adını verdim, "Maximum available space"i seçili bıraktım ve Next'e basıp sihirbazı tamamladım.

ESXi hostların her ikisi de "Storage" bölümünde "sharedstorage" diskini görüyor olmalı (yukarıda). Böylelikle disk konusu tamamlandı.

vMotion, Fault Tolerance ve VM Ağlarının Eklenmesi

Önceki yazıda ESXi hostları vCenter'a eklerken bir tanesinde sorun yaşadığım için ağ kartlarından birini bond dışında bırakmıştım. Bu bölümde, yapılacak işlemin iki host için farklılık gösterdiği yerleri vurgulayacağım.

vSwitch0 Properties

Birinci hostta durum yukarıdaki gibiydi. Görseldeki "vSwitch0"ın "Properties"ine bastım. "VM Network"ü seçip "Remove"a bastım ve çıkan "emin misiniz?" mesajına evet dedim. Malum, en başta vmnic0 veya vmnic1'i "VM Network" için ayırmamıştım. Aynı pencerede "Add"e bastım, "Connection Type" olarak "VMkernel" seçtim. Bu ağ için "Network Label"a vMotion verdim ve "Use this port group for vMotion"ı işaretledim (aşağıda).

Bu ağda kullanılacak IP ve ağ maskesi ilk makina için 10.10.5.1/255.255.255.0 olacak.

vMotion ağı eklendikten sonra "vSwitch0 Properties" penceresini kapatmadım (aynı adlı görsel). Önce vMotion'ı çift tıkladım, açılan pencerede "NIC Teaming" sekmesine gelip "Override switch failover order:"ı işaretledim. vMotion ağında vmnic1'i aktif, vmnic0'ı "standby" olarak ayarladım (aşağıda). Sonra "Security" sekmesine gidip "Promiscuous Mode"u ve "Forged Transmits"i işaretledim ve her ikisini de "Accept"e çektim.

Tamama basıp "vSwitch0 Properties"e döndüm. Bu sefer "Management Network"e çift tıkladım. "vMotion" ağı eklendikten sonra artık "Management Network"ün özelliklerinde "vMotion" özelliğinin "Enabled" olmaması gerekir. Bunu kontrol ettikten sonra "NIC Teaming" sekmesine geçtim, "Override switch failover order:" işaretledim (daha önceden işaretli olabilir). "Management" için vmnic0'ı aktif, vmnic1'i standby olarak ayarladım ('unused' değil). "Security" sekmesinde "Promiscuous Mode"u ve "Forged Transmits"i burada da işaretleyip her ikisini "Accept"e çektim. Tekrar tamama bastım.

esxi5-02 hostundaki durum

İkinci hostta durum yukarıdaki gibiydi çünkü önceki yazıda bağlantı sorunu nedeniyle vmnic1'i bond'dan çıkarmıştım. vSwitch0'ın "Properties"ine bastım ve "Management Network"e çift tıkladım. Burada diğer hostta yapılandan farklı olarak önce "Security" sekmesine gidip "Promiscuous Mode"u ve "Forged Transmits"i açtım, her ikisini de "Accept"e çektim ve tamama bastım. "vSwitch0 Properties" penceresinde önce "Network Adapters" (sağ üstte 1) sekmesinde "Add"a (2) basıp vmnic1'i ekledim (3), sonraki adımda (4) vmnic1'i "Standby"a indirdim ve tamama bastım. Bir hata mesajı verdiyse de vmnic1 eklendi. Tekrar "Ports" sekmesine geçtim. "VM Network"ü sildim (Remove düğmesine bastım). "Management Network"e çift tıkladım, açılan pencerede "NIC Teaming" sekmesine geçtim. vmnic0'ı aktif, vmnic1'i standby olarak ayarladım ve tamama bastım. Sonra ilk hostta yaptığım gibi "Add"e basıp vMotion için bir VMkernel bağlantısı ekledim. Bu arabirimin IP'si ve ağ maskesi 10.10.5.2/255.255.255.0 olmalı. vMotion'ın özelliklerinden "Security" ve "NIC Teaming" sekmelerindeki ayarları diğer ESXi host ile aynı olacak şekilde değiştirdim.

Peki Neden Promisc Mode ve Forged Transmits Açıldı?

Bu önemli bir konu, bu nedenle bunu özellikle ayrı bir başlıkta ele almak gerek. Blogu yazarken bir yandan bu sorunu araştırıyordum. Benimle birebir aynı durumda (Nested ESXi) aynı sorunu yaşayan birinin gönderisini buldum: https://community.spiceworks.com/topic/524798-host-disconnecting-from-vcenter-while-migrating-kernal-port-to-new-switch

Gönderideki bence en önemli ifade, ESXi'nin sanallaştırılmasının kesinlikle tavsiye edilmediği ve sanallaştırılıyorsa kesinlikle üretim ortamında kullanılmaması gerektiği yanıtı. Soruyu soranın kendine verdiği yanıtta (üçüncü) konuyla ilgili başka bir blog yazısının bağlantısını paylaşmış:

Why is Promiscuous Mode & Forged Transmits required for Nested ESXi?

Yazıda vmware'in kullandığı network switch altyapısının fiziksel switch'ler gibi çalışmadığına değinilmiş. Bu son derece mantıklı; fiziksel switch, portlardan gelen "frame"lerin kaynak MAC adreslerini ilgili portun MAC adres tablosuna yazar. Yani, o porta o MAC adresine sahip cihazın bağlı olduğunu "öğrenir". Switch'e bir frame geldiğinde, hedef MAC adresine bakılır. Hedef MAC adresi switch'in MAC adres tablosunda varsa söz konusu frame, o (öğrenilen) porttan gönderilir. Ancak sanal ortamda bu gereksizdir. MAC adreslerini sanal makinalara VMware atadığından, zaten veritabanında bütün MAC'lerin hangi vSwitch'e gitmesi gerektiğini bilir. Sanallaştırılmış bir ESXi host, fiziksel bir switch'e bağlı olmadığını bilemez. Bu yüzden promisc modda çalışmazsa diğer sanal makinaların MAC'lerini bilemez ve drop eder. 

Bu yazıdaki bağlantılardan atlayarak aşağıdaki kaynaklara ulaştım:

Nested ESXi – Reduced Network Throughput with Promiscuous Mode PortGroups

Yukarıdaki kaynakta sanallaştırılmış ve promisc modda çalışan bir ESXi'nin fiziksel ESXi'lerin oluğu bir ortamda ağ performansını olumsuz etkilediği anlatılıyor. 

How The VMware Forged Transmits Security Policy Works

Ara başlığı kapatıp network konusuna geri döneyim. 

ESXi hostları kurduğum ilk yazıda, vmnic0 ile vmnic1'i (vmnic1 yönetim ağına bağlı olmadığı halde) birlikte seçmemin nedenini anlatacağımı söylemiştim. İlk başta tek vmnic'le kurduğum ikinci host şu anda "Summary" sekmesinde şu uyarıyı alıyor: "This host currently has no management network redundancy". Yani vCenter, ESXi hostların yönetim trafiğini en az iki noktadan gönderebilmek istiyor ki biri kesildiğinde host hala yönetilebiliyor olsun. Yönetim trafiği için fiziksel makinada Vmnet2 ağını oluşturmuştuk. Elbette ki burada tek bir switch olduğundan yedeklilikten (redundancy) bahsedilemez. Ancak hem vmnic0'ı hem vmnic1'i aynı switch'te birleştirip birini aktif diğerini "standby" olarak ayarlamakla bir bakıma vCenter kandırılmış oluyor. 

Bu ayar yapıldığı halde uyarı alan bir host varsa "Maintenance mod"a alıp geri döndürünce düzelmesi gerekir. Host, sağ tıklayınca gelen menüde "Enter Maintenance Mode"a basılarak bu moda alınır. "Maintenance mode", ESXi'nin üzerinde çalıştığı makinada çalışma yapılacağı zaman kullanılır. Bu moda girince, hosttaki sanal makinalar kümedeki diğer hostlara taşınır. Sonrasında makina sorunsuz kapatılabilir veya yeniden başlatılabilir. Ben yeniden başlatmadan "maintenance mode"a alıp geri döndürdüm ve yönetim arayüzüyle ilgili aldığım uyarı kayboldu. 

Hostun "Configuration" sekmesinde "Networking"e geri döndüm. Yeni bir vSwitch daha oluşturmak üzere "Add Networking"e bastım; "VMkernel"ı ve sonrasında vmnic4'ü seçtim. "Network Label" FT olmalı (sağda) ve "Use this port group for Fault Tolerance logging" işaretli olmalı. Bu arabirime birinci makinada 10.10.4.1/255.255.255.0 IP ve ağ maskesini verdim. Aynısını ikinci makinada tekrarlayıp IP'yi 10.10.4.2 olarak ayarladım. Bu arada FT için de "promisc mod" ve "forged transmits" açmak gerekiyor.

Tüm hostlarda, son bir vSwitch daha oluşturulmalı. "Add Networking"e basıp "Connection Types"da "Virtual Machine" seçtim. Bir tek vmnic5 kullanılmamıştı, onu seçtim. Bu ağın adının ne olduğu önemsiz. Hiç bir ayarı değiştirmeden sihirbazı tamamladım. Bu vSwitch'te de "promisc mod" ve "forged transmits"i açtım.

Bu ağ, sanal makinaların bağlanacağı ve aralarındaki trafiğin akacağı vSwitch. Normalde, üretim ortamında bundan birden fazla olacaktır çünkü farklı görevleri olan veya farklı kişilere ait makinaların hepsini tek bir ağa koymak güvenli olmaz. Ayrım iki farklı şekilde yapılabilir. (a) Farklı fiziksel switch'lerle veya (b) aynı switch'teki farklı VLAN'lerle. "Vmware network editor"le trunk portu olan switch oluşturamadığımdan (Ek okuma: trunk port ve access port nedir?) VLAN ID'yi boş bıraktım. Fiziksel makinamda bir tane daha Vmnet oluşturup, ESXi'lerde de bir ağ kartı daha ekler ve bu kartı yeni Vmnet'e bağlayarak fiziksel ayrım yapabilirdim (a). İkinci olasılık, trunk portum olsaydı aynı vSwitch üzerinde farklı VLAN ID ve adla bir arabirim eklersem bunu VLAN'lerle yapmış olurdum (b).

vCenter'in yönetim ağında yedeklilik olmadığında uyarı verdiğini söylemiştim. Eğer yönetim ağı sanal makinaların kullandığı ağdan fiziksel olarak farklıysa, yönetim ağındaki kesinti ESXi hosta ulaşılamamasına neden olur ama sanal makinalar çalışmaya devam eder ve erişilebilir durumdadırlar. Sanal makina ağında oluşacak bir kesinti o hosttaki sanal makinalara ulaşılamamasına neden olur ki üretim ortamında aslında daha ciddi sonuçları olacaktır. Bu nedenle yönetim ağından çok sanal makina ağında yedeklilik önemlidir.

LDAP Kullanıcısı Ekleme ve vCenter'da Yetkilendirme

vCenter makinası lab.local domaininde olduğu için vCenter sunucusu da lab.local domain'iniyle tümleşik çalışır. Yani herhangi bir ek ayar yapılmaksızın lab.local domain'indeki tüm kullanıcılar vCenter'da yetkilendirilebilir. Domain'de kullanıcı eklemek için DC makinasının konsoluna geçtim. Başlat menüsünde "All Programs -> Administrative Tools -> Active Directory Users and Computers"i açtım (kısayoldan Başlat -> Çalıştır -> dsa.msc). lab.local domain'ini açıp "Users"a bastım. Sağda varolan kullanıcılar ve gruplar listelenecek. Makina yeni kurulduğu için kullanıcıdan çok grup var. Boş bir yere sağ tıklayıp New -> User'i seçtim (sağ üstte). Yeni kullanıcı eklerken "First name" ve "Last name"in önemi yok. Bu alanlar daha çok açıklama için ama kullanıcılar bu ada göre listelendiğinden açıklayıcı adlar kullanmak gerekiyor. "User logon name" asıl kullanıcı adı olacak. Bunları doldurup Next'e bastım. Sonraki adımda bir şifre verdim ve "Password never expires"a bastım. Bu, "User must change..." ayarıyla çakıştığından bir hata mesajı görünecek ve o ayarın işareti kaldırılacak. Next ve sonra Finish'e basınca yeni kullanıcı oluşturuldu. Bu kullanıcı domain'deki bütün makinalara girebilir. İstenirse kullanıcıya sağ tıklayıp "Properties" açılır ve "Member Of" sekmesinde grup eklenerek yetkisi genişletilebilir. Şu anda buna ihtiyacım yok. Pencereyi kapatıp vCenter makinasına geri döndüm.

Kullanıcı, vCenter makinasına LAB\<kullanıcı_adı> olarak şifresiyle girebilir ama henüz vSphere'e yetkilendirilmedi. Web arayüzünden bağlanabilir ama değişiklik yapamaz. Kullanıcıyı yetkilendirmek için vSphere istemcisini yönetici hesabıyla açtım. İstemcinin üst satırında "Home -> Inventory -> Hosts and Clusters" (1) seçili olmalı. Aşağıda soldaki "vcenter.lab.local"e bastım (2) ve sağda "Permissions" sekmesine geçtim (3). Sağda boş bir yere (4) sağ tıklayıp "Add Permission"ı seçtim. Çıkan pencerede kullanıcı eklemek için "Add"e bastım (5) ve LAB domainini seçtim (6). Bu seçilince vCenter, DC ile konuşup kullanıcıları listeleyecek. Kullanıcıyı seçtim (7), "Add"e (8) ve sonra OK'e basınca kullanıcı eklendi. Sağ tarafta "Assigned Role" olarak "Administrator" verdim (10) ve tamama bastığımda kullanıcı artık bu vCenter'a bağlanmaya yetkilendirilmiş oldu. Ayrı bir istemci açıp bu kullanıcıyla bağlanabildim. Kullanıcının yönetici yetkisi olduğundan bundan sonraki bölümde anlatılacaklar bu kullanıcıyla yapılabilir ama ben yazıyı hazırlarken Administrator'u kullanmaya devam ettim.

Sanal Makina Kurulumu, Taşınması ve FT

Makaledeki örnekte bir XP makina kurulmuş ama XP'nin iso'su biraz büyük olduğundan ben CentOS 6.9 minimal tercih ettim. Kurulum için iki yol var, biri vCenter makinasının diskini büyüteceğinden kısaca söz edeceğim. CentOS 7.x serisi yalnızca x86_64 olduğundan makina taşırken sorun çıkarmaz ama FT'de sorun çıkaracaktır. CentOS netinstall dağıtımının kalıp dosyası daha küçük olduğu halde VM ağında internet olmayacağından kurulamayacaktır. Sanal makinada, damn small linux (DSL) gibi bir dağıtım kullanılabilir ancak sanal makinanın diski de olsun istiyorum.

Anlatacağım ama uygulamayacağım yöntem, kalıp dosyasını vCenter makinasına indirip sanal makinaya dosyayı doğrudan (konsoldan) veya datastore'lardan birine kopyalayıp datastore'dan göstermek. Bunu uygulamak pratik değil.

Dosyayı fiziksel makinama indirdim. Makina taşıma için x86_64 veya i386 olmasının önemi yok ama FT özelliği için sanal makina i386 olmalı. Ben bu örnekte x86_64 kurdum. Sonraki örnekte bunları silip başka makina kuracağım. Kalıp dosyasını 'VMware Workstation'dan vCenter makinasına taktım. Daha önce vSphere kurulumu için de yapılmıştı bu yüzden ayrıntısına girmiyorum. Birinci ESXi hosta sağ tıkladım ve "New Virtual Machine"i seçtim. "Configuration"da "Typical"ı seçili bıraktım. Sanal makinaya "Centos" adını verdim. Sonraki adımda makinanın hangi diskte kurulacağını soruyor. Burada "sharedstorage"ı seçtim. ESXi kurulurken, makinanın "datastore" olarak kullanabileceği ikinci diski olup olmadığını kontrol eder. Eğer başka disk yoksa diski ikiye böler ve ikinci bölümü "datastore" olarak formatlar. Listedeki iki "datastore" o şekilde oluşturulmuş yerel disklerde. Bir makina, diğerinin üzerindeki (paylaşımsız) diski göremez. Paylaşımlı diski bu yüzden eklemiştim. "Guest Operating System" Linux ve sürüm RedHat Enterprise Linux 6 (64-bit) olmalı. Sonraki adımda makinanın kaç ağ kartı olacağı seçiliyor. Olduğu gibi bırakıp geçtim. Disk olarak "Thin Provision" seçtim. Datastore toplamda 10 GB (bende 8.9 GB'ı boş) ve sanal disk 16 GB olduğundan "Thick Provision" seçilemez. Makinanın diskinin Thin seçildiği ve kurulacağı datastore'dan büyük olduğuna dair bir uyarı alınacak. Buna tamam diyip sihirbazı tamamladım ve sanal makina oluştu.

Sağ tuş menüsü

Sanal makinaya sağ tıklayıp "Edit Settings..." seçilerek özelliklerine göz atılabilir. Burada herhangi bir değişiklik yapmadım. Bunun yerine "Open Console" diyerek makinanın konsolunu açtım ve yeşil üçgene basıp makinayı başlattım (sağ üstte 1). Sonra sağ taraftaki CD simgesine basıp D: sürücüsünü sanal makinaya CD olarak tanıttım (2). Açılır açılmaz CD bulamadığından PXE boot'a geçti. VM (3) menüsünden Guest -> "Send Ctrl + Alt +Del" diyip makinayı yeniden başlattım ve "Install..."ı (ilk seçenek) seçtiğimde CentOS kurulumu başladı. İlk adımda "Skip"i seçtim. Altyapıyı denemek için basit bir sanal makina gerekli, fazla birşey kurmayacağım. Yalnızca klavyeyi ve saat dilimini seçtim, root şifresini verip başka birşeye dokunmadan kurulumu tamamladım. Kurulum bitince D: sürücüsüyle sanal makinanın bağlantısını kestim.

Deneme için ikinci bir sanal makina daha gerekli. 'Centos'a sağ tıklayıp Clone'u seçtim. Klonlanacak makinaya Centos2 adını verdim, sonraki adımda DC-Lab altında Prod kümesini seçtim. Makinayı "sharedstorage" diskine koydum ve klonlamayı başlattım, bitince de sanal makinayı açtım. Her iki makinanın konsolundan bağlandım ve "ifconfig -a" çıktısına baktım. Birincisinde eth0 ikincisinde eth1 var çünkü kurulum birincisinde yapıldı ve ikincisi klon olduğundan birincinin aynısını bir /etc/udev/rules.d/70-persistent-net.rules dosyası var. Bu dosya MAC-eth eşleştirmelerini tutar. Centos2'nin ağ kartına, klon alırken yeni bir MAC adresi atandı. İşletim sistemi açılışta eth0'a ait geçersiz bir kayıt gördü, bunun sökülmüş bir kart olduğunu düşünüp yeni MAC adresli karta eth1 adını verdi. Bu çok önemli değil. Sanal makinalarda aşağıdaki komutları çalıştırıp IP verdim:

Centos : ifconfig eth0 up 172.16.0.1 netmask 255.255.255.0

Centos2: ifconfig eth1 up 172.16.0.2 netmask 255.255.255.0

Artık herhangi bir makinadan diğeri ping'lenebiliyor (ping -c 3 172.16.0.1).

İpucu: vCenter makinası 1024x768'de çalışıyor ve tam ekran yapmak istemedim. Ama CentOS konsolu masaüstüne sığmadı (yukarıda). Bunu ekrana sığdırmak için /boot/grub/grub.conf dosyasını açtım. kernel'la başlayan satırın sonuna vmwgfx.enable_fbdev=0 video=640x480 ekleyip dosyayı kaydettim. Makinaları yeniden başlattığımda sonuç yandaki gibiydi.

IP'leri kalıcı vermediğimden makinalar açıldıktan sonra IP'lerini tekrar verdim. Yukarıdaki ekran görüntüsünde konsolun başlığına dikkat çekmek istiyorum. Centos "esxi5-01.lab.local"de Centos2 "esxi5-02.lab.local"de çalışıyor. IP'leri verdikten sonra Centos2'den Centos'u ping'lemeye başladım (ping 172.16.0.1). Diğer yandan Centos makinasının konsolunu kapatıp vSphere'e döndüm. Centos makinasına sağ tıklayıp "Migrate"i seçtim (sağ tuş menüsü altbaşlıklı görselde "Edit Settings"in altında). İlk adımda "Change Host"u seçip ikinci adımda Centos makinasının çalışmadığı hostu seçtim. "Compatibility: Validation succeeded" yazınca Next'e bastım, "High-priority"i seçili bırakarak sihirbazı tamamladığımda Centos makinası çalıştığı "esxi5-01.lab.local" makinasından "esxi5-02.lab.local" makinasına taşınmaya başladı.

Bu sırada Centos2'nin konsoluna döndüğümde ping'lerin uzun sürse de devam ettiğini, ciddi bir kayıp yaşanmadığını gördüm. Canlı taşıma (migration) özelliği ilk yazıda da bahsettiğim, vCenter'ın güzel özelliklerinden. Taşıma bitip konsolda CTRL+C ile ping'i kestiğimde en fazla 7891ms'lik ping yanıtı görünüyordu ve 500'e yakın paketten yalnızca üçü kaybolmuştu. Bu normalde kabul edilemeyecek bir süre ancak fiziksel makina donanım sınırlarında çalıştığından lab ortamı için normal sayılabilir. Taşıma üç dakika civarında sürdü. İlgi çekici diğer bir nokta da, bir önceki yazıda kümeyi oluştururken DRS özelliğini açmıştım. DRS'in açılımı Dynamic Resource Scheduler yani kaynakların olabildiğince dengeli kullanılmasını sağlayan bir servis. Makina taşındıktan otuz saniye sonra DRS makinayı boşta duran hosta geri taşıdı (yukarıda, recent tasks bölümünde). Bir makina açılırken DRS devreye girer ve kaynağı en uygun hostu seçer. Bir makina kapandığında DRS boşalan kaynağa başka makinaları taşıyıp yükü dengeler. DRS'le ilgili ayarlar için "cluster"a sağ tıklayıp çıkan menüde "Edit Settings"i seçmek gerekiyor. "Cluster Features"a basınca sağ taraftan DRS servisi açılıp kapatılabilir. "vSphere DRS"e basınca sağ taraftan DRS'in davranışı değiştirilebilir. Bu pencere açıkken bir sonraki bölüm için "vSphere HA"ya basıp "Admission Control" altında "Disable"ı seçtim ve tamama bastım. Bunun işlevini FT'den hemen sonra anlatacağım.

Bu deneyi yaptıktan sonra makinalar x86_64 olduklarından artık bunlara ihtiyacım kalmadı. Konsoldan poweroff komutunu verip makinaları ve konsollarını kapattım. Makinalara sağ tuşla tıkladım "Delete from disk"i seçip tamamen sildim.

Bu sefer CentOS 6.9'un 32 bitlik olanını [ CentOS-6.9-i386-minimal.iso ] indirdim ve vCenter makinasına taktım. 'Prod'a sağ tıklayıp "New Virtual Machine..."i ve kurulum için "Custom"ı seçtim (sağda). Sanal makinaya "Centos32" adını verdim. DRS açık olduğundan hostun da önemi yok, ESXi5-01 seçili kalabilir. Yine "sharedstorage"ı seçtim, sanal makina sürümünde v8 seçiliydi, olduğu gibi bıraktım. "Guest Operating System" olarak Linux ve sürümü "RedHat Enterprise Linux 6 (32-bit)" olmalı. Makinanın belleği 512 MB RAM (64 bit CentOS 512 MB RAM'de çalışamıyor) seçtim. Diske kadar diğer ayarlara dokunmadım. Bu makina için büyüklüğü 2 GB ve "Thick Provision Eager Zeroed" yeni bir disk oluşturup (aşağıda), sihirbazı tamamladım. Daha önceki ayarlarla aynı şekilde CentOS'u kurdum yalnız makina 512 MB RAM'li olduğundan kurulum metin ekranda gerçekleşti.

Kurulum sürerken ESXi web arayüzüne [ https://esxi5-02.lab.local ] girdim ve "Browse datastores in this host's inventory"e bastım. ESXi'ın kullanıcı adı ve şifresini girdim. Burada hosta bağlı olan tüm datastore'ları gösteriyor. Bir tane yerel datastore'u bu makina göremediğinden listede bulunmuyor. "sharedstorage"a basınca Centos32 sanal makinasının dizini, bunun içinde sanal disk dosyaları, swap dosyası vb. dosyalar görülebiliyor. ESXi web arayüzünün bir özelliği de bu.

Sanal makinada FT ayarlarının açılması

Kurulum bitip "Reboot" düğmesi çıkınca Ctrl+Alt+F2'ye basıp komut satırında poweroff yazdım. Makina kapanınca VM menüsünden (sağda) "Edit Settings..."e bastım. Makinanın ince ayarlarıyla oynamak için "Options" sekmesine (1) ve onun içinde "Advanced" altındaki "General"a (2) bastım. Ardından sağdaki "Configuration Parameters" (3) düğmesine bastım. Makinanın ayarları için bir pencere açılacak. Windows için registry neyse sanal makina için de burası o. "Add Row"a basıp (4) aşağıdaki ayarları girdim:

replay.allowBTOnly = true
replay.allowFT = true
replay.supported = true

Son girilen değer ekran görüntüsünde görünmüyor ama doğru yazıldıktan sonra önemli değil. Bunlar tamamlandıktan sonra her iki pencerede tamama (6 ve 7) basıp kapattım. Sanal makinaya sağ tuşla tıkladım "Fault Tolerance" altında "Turn On Fault Tolerance"a bastım ve çıkan soruya evet dedim. Makinanın simgesi koyu maviye döndü. Makinayı başlattım. 

Fault Tolerance (FT) Nedir? 

FT ile çalışan bir sanal makinanın genel görünümü

vCenter'da kesinlikle kapanmaması gereken çok önemli makinalar FT özelliğiyle yedeklenebilir. Bu durumda, sanal makina esas çalıştığı makina dışında ikinci bir makinada daha açılır ve esas makinadaki her şey log olarak ikinci makinaya gönderilir. Doğal olarak bunun için fazladan kaynak ayrılır ve diski Thick'e dönüşür. Bu nedenle makinayı çok küçük bir kaynakla kurdum. Buna rağmen FT'yi açabilmek için kümenin kaynak kullanımını denetlemesini de kaldırmak zorunda kaldım (admission control: disable). Maalesef bu özellik 64 bit CentOS için desteklenmediğinden (veya ben bulamadığımdan) 32 bit işletim sisteminde gösterebildim.

Yukarıdaki görselde sanal makinanın çalıştığı host esxi5-01 ama FT makinayı yedekliyor. "Secondary Location" yedek makinanın çalıştığı host. Yedek makina 39 ms geriden geliyor ve log'lar yedek makinaya 11 KBps ile aktarılıyor. Eğer esas makina üzerinde birşey yapıyor olsaydım aktarımlar artacak, öyle ki lab ortamı yavaş kaldığında, kopmalar olacaktı. Makina ilk açıldığında veya kopma olduğunda "Not protected" duruma düşer ve ikincil makina senkron olana kadar öyle kalır. Yukarıda iki makina senkron durumda. İkinci hostta çalışan sanal makinalara baktığımda (sol yukarıda) Centos32'nin burada ikincil olarak çalıştığını gördüm. Sanal makinanın (salt okunur) konsolunu açtım. FT'yi denemek için VMware workstation'da ESXi5-01'e sağ tıklayıp "Power" menüsünden "Reset"e bastım. Bunu yapar yapmaz Centos32 makinası "Not protected" altında da "Need Secondary VM" durumuna geldi. Makinanın konsolundan çalışma süresine baktığımda sanal makina reset'ten etkilenmediğini gördüm:

ESXi5-01 geri açıldığında sanal makina tekrar Protected duruma döndü. Eğer ortamda ikiden fazla host olsaydı ESXi5-01 açılmasından önce ikincil kopya üçüncü bir hostta tekrar oluşturulacaktı.

Buraya kadar yazdıklarım, referans aldığım makaledeki FT kısmını biraz genişletmem dışında çoğunlukla o makalede geçen konulardı. Bu yazı biraz uzun oldu, umarım takip etmek açısından zor olmamıştır. Bundan sonraki bölümde, buraya kadar anlattığım altyapıyı kendim linux'ta kuracak, makalede konu edilen "vCenter Virtual Appliance" konu başlığını içeriğinden bağımsız olarak kendim ele alacağım.

Yazının devamı: Altyapının Linux'ta Kurulması, vCenter Appliance Kurulumu ve Ayarları