Reklamlar

Software Defined Storage – VMware VSAN

Öne Çıkan

Etiketler

,

Günümüzde sık sık duyduğumuz trendlerden biri olan yazılım tabanlı veri merkezi (software defined data center) konseptinin bir parçası da yazılım tabanlı veri depolama sistemidir (software defined storage). Storage sanal veri merkezinin en önemli birimlerinden biridir. Bu yeni mimariyi de isimlendirirken; geleneksel veri depolama sistemlerini oluşturan yapının, “kurulumunun, yönetiminin ve kullanımının” daha basit bir şekilde sunulmuş halidir diyebiliriz. Çünkü mevcut geleneksel storage ürünlerinin kurulumu/konfigürasyonu/işletimi kolay değildir. Şimdiye kadar storage deyince aklımıza genel olarak SAN – NAS, fiber channel / ethernet switch, kablolama, disk pool, RAID, protokoller, controller ve disk ünitesinden oluşan karmaşık bir kutu çözümü gelmektedir. Bu donanımın da yönetimi için storage yöneticilerine ihtiyaç duyulmaktadır. VMware de sunucu sanallaştırmadaki başarısını, bu alana taşıyıp, yazılım tabanlı veri depolama çözümü olarak VMware VSAN ürünü geliştirdi. Aslında zamanda bu ürün Hyperconverged (Hiper bütünleşik) sistem başlığı altında da konumlandırılmaktadır. Çünkü bu bakış açısında sunucu ve storage bir arada, sanallaştırma için gerekli kaynağı sunmaktadır. Storage için ayrı bir kutuya ihtiyaç yoktur. Bu da bize maliyet ve yönetim avantajı sağlamaktadır.

Storage deyince aklımıza gelen aşağıda saydığımız parçalar geleneksel storage mimarisinde olduğu gibi yine software defined storage mimarisinde de kullanılmaktadır. Ama bu platformda, gerçekte işi yapan “veri yönetim yazılımı” daha ön plandadır ve mevcut x86 sunucu mimarisini kullanmaktadır. Kısacası veri depolamak için ayrı bir storage kutusunu veri merkezine koymamıza genelde gerek kalmıyor. Genelde diyorum çünkü bu yeni teknolojinin daha da geliştirmeye ve yeni servisler ile içeriğinin zenginleştirmeye açık olduğunu düşünüyorum. Örneğin NAS servisleri de bu mimaride hizmete sunulmalıdır. Storage denildiğinde öne çıkan terimleri bir hatırlayalım:

  • Disks / Storage shelf
  • Storage controller (CPU/Memory)
  • Storage operating system
  • Disk Pool (Array / Datastore)
  • Cache
  • RAID
  • Network
  • Protokol
  • Storage Fabric
  • Storage Policy Based Management
  • System Management
  • Cost

Bu parçaların her iki konsepte de kullanımına bir bakalım.

Component

Traditional Storage

Software Defined Storage (VMware VSAN)

Disks / Storage Shelf
  • Veri depolamak için fiziksel disklere ihtiyaç duyar.
  • Değişiklik yok. Aynı iş için kullanılır.
Storage Controller (CPU/Memory)
  • Veriyi işlemek için CPU ve memory gereklidir.
  • Aslında her bir storage içerisinde bunun için bir server bulunur ama biz buna controller deriz.
  • Ayrı bir fiziksel donanıma ihtiyaç duymaz. Mevcut ESXi host kullanılır.
Storage Operating System
  • Veriyi yöneten, koruyan ve fiziksel kaynakları kullanarak kullanıma sunan ayrı bir yazılımdır.
  • Ayrıca yönetilmesi gerekir.
  • VMware VSAN, ESXi içerisine gömülü bir servistir. Lisans ile birlikte aktif edilir. Dolayısıyla ayrı bir kuruluma gerek yoktur.
Disk Pool (Array / Datastore)
  • Diskler shelf sayesinde controller a bağlanır.
  • Fiziksel disklerde önce bir grup oluşturulur.
  • Disk grupları disk havuzunu oluşturur.
  • Veri koyabilmek için Volume/Lun oluşturulur.
  • Seçilen protokol üzerinden bu alan sunucuya gösterilir. Özel yapılandırma yapılır.
  • Sunulan bu alan ESXi tarafından formatlanır.
  • Datastore haline gelir.
  • Kullanıma sunulur.
  • Fiziksel diskler sunucuya bağlanır ve herhangi bir config yapmadan direkt ESXi sunucuya gösterilir.
  • Disk claim işlemi ile disk grupları oluşturulur.
  • Disk grupları VSAN datastore u oluşturur.
  • kullanıma sunulur.
Cache
  • Storage controller ya da array bazında cache kart takılır veya flashpool ile bu hizmet sağlanır.
  • Her disk grup bir cache (SSD) disk içerir.
RAID
  • Disk katmanında bu hizmet sunulur.
  • Birden fazla RAID tipi desteklenir.
  • VM bazında RAID hizmeti sunulur. Dolayısıyla bu size daha fazla esneklik sağlar. Test VM leri RAID 0, canlı sistemleri RAID 1 veya RAID 5 olarak konumlandırabilirsiniz.
  • Raid0, Raid1, Raid5, Raid6, Raid10
Network
  • SAN ve NAS çözümleri bulunmaktadır.
  • SAN için özel donanımlar alınmalı ve ayrı bir yatırım yapılmalıdır.
  • Sadece Ethernet tabanlı olarak kullanılmaktadır.
  • SAN cihazlarına gerek yoktur, mevcut IP tabanlı network kullanılır.
Protokol
  • SCSI protokol kullanılır.
  • NVMe desteği de birçok üreticide gelmiştir.
  • Disk seviyesinde SCSCI protokol kullanılır.
  • NVMe desteği mevcuttur.
Storage Fabric
  • Active Active storage cluster ile anlık veri replikasyonu yapılır ve felaket senaryolarına ve iş sürekliliğine çözüm olarak sunulur.
  • Backend (storage-to-storage) FC ve IP desteği bulunur.
  • Kurulumu maliyetli ve zordur.
  • Streched cluster (Active-Active) ile anlık veri replikasyonu yapılır ve felaket senaryolarına ve iş sürekliğine çözüm olarak sunulur.
  • Mevcut IP network üzerinden haberleşir. Ekstra backend yatırımına gerek yoktur.
  • Kurulumu kolaydır.
Storage Policy Based Management
  • Disk tipine göre katogorize edilir. (SATA – silver, SAS – bronz, SDD – gold)
  • Tüm VM ler bu kategorilerden birine atanır.
  • Sanal makinenin performans, erişilebilirlik, kapasite ihtiyacına göre politika belirlenebilir.
  • Sanal makine bazında yapıldığından daha özgür bir kullanım sunulmaktadır.
System Management
  • VMware vCenter + Storage Management Software
  • Sadece VMware vCenter kullanmanız yeterlidir.
Cost
  • Maliyeti yüksektir.
  • Kurulum, kullanım özel know-how gerektirir.
  • Verimlilik tekilleştirme ve sıkıştırma ile sağlanmaktadır.
  • Özel donanımlara ihtiyaç duyar.
  • Maliyeti düşüktür.
  • Kurulumu ve kullanımı kolaydır. Sanal ortam yöneten herkes VSAN ı da yönetebilir.
  • Verimlilik için tekilleştirme ve sıkıştırma teknolojileri kullanır ama çok yüksek bir beklenti içinde olmamak gerekir. Genel kullanımlı bir sanal ortamda 1:2 doğru bir tahmindir.
  • Özel donanımlara ihtiyacı yoktur. Sunucu + Disk + VSAN lisans

Yukarıdaki karşılaştırma tablosunda da görüleceği üzere, VMware VSAN ürünü yazılım tabanlı veri depolama sistemi olarak (bütünleşik sistem de diyebiliriz) bize maliyet ve yönetim kolaylığı avantajları sunmaktadır. Her ne kadar geleneksel ürünler veya üreticiler arasında ufak tefek farklılıklar sunulmuş olsa da genel olarak storage konsepti yukarıdaki başlıklardan oluşmaktadır.

Yakın gelecekte ise beklenti geleneksel mimari yerine yeni veri depolama mimarisinin daha fazla kullanılacağını göstermektedir. Aşağıdaki tablo da piyasadaki bu beklentiyi yansıtmaktadır. Burada en belirgin faktör para olarak görünse de aynı zamanda esneklik te önemli bir faktördür. Çünkü yeni yapıda politika tabanlı yönetim bize bu esnekliği sağlamakta ve iş birimlerinden gelen ihtiyaca ve veri kritikliğine göre daha rahat hareket edebilmemize olanak sağlamaktadır.


Source: Veeam Blog

Sanal ortam perspektifinden bakıldığında da aslında değişen bir şey yoktur. Yine paylaşımlı storage üzerinde sanal makinelerimizi konumlandırıp bize disk hizmeti sunulmaktadır. Sadece iş biraz daha IP tabanlı bir yazılım üzerine kaydırılıp daha kolay bir hal almıştır. VMware VSAN ürünü de bu hizmeti bize tanıdık bir ortam ve arayüz olan vCenter üzerinde sağlamaktadır. Aşağıdaki tablo da kurulum/yönetim kolaylığını özetlemektedir.

VM VM
VMware File System VSAN File System
LUN (datastore) Disk Group
Volume
Aggregate
Raid
Plex
Disk Shelf Server with Disks
Storage Controller
Storage Area Network (SAN) Ethernet Network

Hyper-converged bir teknoloji olarak adlandırılan VMware VSAN kullanılarak yapılacak bir yatırımda en çok dikkat etmeniz gereken başlıklardan biri de uyumluluktur. Bu teknolojiyi çalıştıracağınız ortamda üretici size iki alternatif önermektedir. İsterseniz elinizdeki donanımlarınızla ya da yeni alacağınız sunucu/disk donanımlarınız kendi VMware VSAN ortamınızı kurabilirsiniz. Ya da ikinci alternatif olarak daha önceden konfigüre edilmiş, testleri yapılmış ve sertifikalandırılmış kutu çözümlerini de kullanabilirsiniz. Örneğin Lenovo ThinkAgile VX Series, Dell EMC VxRail ürünleri gibi. Üreticiler sunucu, disk ve VSAN kurulumlarını sizin için önceden yapıp, gerekli tüm süreçleri tamamlayıp size hazır bir cihaz olarak içerisinde VMware VSAN çalışır halde kutu çözümlerini sunmaktadır. Ancak siz kendi seçeceğiniz ya da kullandığınız mevcut sunucu donanımlarınızı VSAN ile kullanmak isterseniz, iş başlamadan önce ilk adım olarak uyumluluk kontrollerini kesinlikle yapmanız gerekmektedir. VSAN çalıştıracağınız donanımın VMware tarafından testlerinin yapılmış ve sertifikalandırılmış olması önemlidir. Çünkü verilerinizi emanet edeceğiniz bu yeni yapının güvenilir olması şarttır. Bu nedenle VMware Compatibility web sitesinde kullanacağınız donanımların uyumluluğunu kontrol etmenizi kesinlikle tavsiye ederim.

Link: VMware Compatibility Guide – VSAN

Kurulan yapının izlenmesi ve oluşacak sorunlarla ilgili alarmların üretilmesi de ayrı bir iştir. Bu konuda vCenter üzerinde VMware VSAN lisansları girilmiş ve yapılandırması tamamlanmış cluster lar için “Monitoring” tab altında VSAN kısmı otomatik karşınıza gelmektedir. Buradan performans, kapasite, gecikme gibi önemli birçok parametreyi takip edebilirsiniz. Ayrıca vCenter içerisinde de öne tanımlı olarak birçok vSAN alert bulunmaktadır. Kurulum sonrası bunları aktive ederek kullanabilirsiniz. İsterseniz sorun oluşturduğunda kendine mail atmasını da kolaylıkla sağlayabilirsiniz. Kısacası normal şartlarda VSAN Monitoring için ayrı bir yatırım yapmanıza gerek yoktur. VMware vCenter üzerindeki hazır tablolar, alarmlar bu ihtiyacınız karşılayacaktır. Eğer daha gelişmiş bir izleme istiyorsanız VMware VROPs ürününe bakmanızı tavsiye ederim.

Not: VMware VROPs basic monitoring için vCenter kullanıcılarına kısıtlı bedava bir kullanım da sunmaktadır. Satın aldığınız VSAN lisansınıza göre bunu da kontrol etmenizi tavsiye ederim.

Yedekleme konusu da önemli. VMware VSAN ortamı kurdunuz ve sanal makinelerinizi Storage vMotion ile eski geleneksel veri depolama ünitesinden yeni ortamınıza taşıdınız, peki yedekler nasıl alınacak? Bu aşamada ben kendi ortamımda Veeam kullanıyorum. Önerilen Veeam Virtual Proxy ile bu işi yapmanızdır. Ancak 10 gig network olan bir ortamda ben SAN de nasıl backup alıyorsam (fiziksel Veeam backup proxy) aynen VSAN a geçtikten sonra da devam ettim. Backup joblarımı re-organize ettim. Yoluma devam ettim. Yeni ortamda Veeam ile aldığım backupların sürelerinin de iyileştiğini gözlemledim, SAN den Ethernet network e geçmemize rağmen backup sürelerim kısaldı.

Özetlemek gerekirse, iş ihtiyaçlarınızı en iyi siz bilirsiniz. İhtiyacınızı en verimli ve en uygun maliyetle adreslemek işinizin bir parçasıdır. Storage tarafında yeni bir yatırım yapacaksanız, kesinlikle VMware VSAN a göz atmanızı tavsiye ederim. Bende bir tavsiye üzerine bu ürüne yöneldim, aynı anda hem sunucu ihtiyacımızı hem de storage ihtiyacımızı All Flash olarak tek bir storage bütçesi ile karşıladık. Kısacası bir taş ile 2 kuş vurmuş olduk.

Dünya değişiyor, IT çok daha hızlı değişiyor! Storage alacak sistem yöneticileri için kesinlikle değerlendirmeye değer olduğunu düşünüyorum.

 

VMware VSAN APD Issue – HPE Smart Array Controller Firmware and Driver

Öne Çıkan

Etiketler

, , , ,

HPE tarafından beklenen VSAN sertifikalı HPE P416ie-m ve P204i-c smart array controller için firmware ve driver yayınlandı. Linkler aşağıdadır. Diyebilirsiniz ki ” Bu zaten normal bir durum, üretici yeni firmware ve driver zaten düzenli olarak yayınlıyor.” Haklısınız evet bu gayet normal. Ancak VSAN kullananlar ve ortamını vSphere 6.7 U2 ye upgrade etmek isteyenler yada etmiş olanlar için bu güncellemeler çok önemli. Ayrıca geçtiğimiz hafta VSAN cluster da tüm sanal makinelerim bir bakım sırasında, bir anda kapandı. Tüm VSAN cluster üyesi hostlar da ilginçtir, “APD” hatası vardı. Daha önce sizlerle paylaştığım HPE Advisory de bahsedilen bug a denk geldim ve bu fena halde başımı ağrıttı. Dolayısıyla son bir aydır devamlı takip ettiğim ve beklediğim bu güncellemenin gelmesine o yüzden çok sevindim ve sizlerle bu sıcak bilgiyi hızlıca paylaşmak istedim.

Sanal ortamda sorun yaşadığımda ESXi hostlarda görülen hata mesajı aşağıdadır.

Sanal sunucu seviyesinde de VM lerde IO error görülmekteydi.

Sorun yaşanılan driver ve firmware versiyonu aşağıdaki gibidir. Ayrıca HPE Advisory sayfasında bu ve alt versiyonlarda da sorun yaşanabileceği bilgisi iletilmiştir.

Model         : HPE P416ie-m Smart Array Controller

Firmware     : 1.98

Driver         : smartpqi

Driver    Version    : 1.0.3.2302-1OEM.670.0.0.8169922

Model         : HPE P204i-c Smart Array Controller

Firmware    : 1.98

Driver         : smartpqi

Driver Version    : 1.0.3.2302-1OEM.670.0.0.8169922

HPE tarafından önerilen ve VMware inde vSphere 6.7 U2 test edip onayladığı versiyonlar ise aşağıda gibidir. Eğer ortamınızı 6.7 U2 upgrade ettiyseniz ve VSAN HPE Synergy sunucular üzerinde çalışıyorsa, acil bu versiyonlara geçmeniz tavsiye edilmektedir.

Önerilen firmware versiyonu 1.99, driver versiyonu da 1.0.3.2309-1OEM.670.0.0.8169922

HPE Firmware Link: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_a0d218762f5e49a3861d982817#tab-history

VMware Driver Link: https://my.vmware.com/web/vmware/details?downloadGroup=DT-ESXI67-MICROSEMI-SMARTPQI-1032309&productId=742

HPE Advisory Link: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00071158en_us

Bu arada HPE Synergy sunucular üzerinde VMware VSAN kullanıyorum. Önerilen son çıkan HPE Synergy SPP bundle paketinin de yukarıdaki driver ve firmware upgrade öncesi ortamda bulunan HPE SYnergy şase ve blade sunucular geçilmiş olmasıdır. Sonrasında yukarıdaki paketleri yüklemeniz tavsiye edilendir.

VMware VSAN Compatibility Guide websitesinden de güncel versiyonları takip edebilirsiniz.

Link : VMware VSAN Compatibility Guide

Bu siteye ulaştığınızda eğer benim gibi VSAN ready node kullanmıyorsanız, o zaman sayfanın orta kısmında bulunan linke “Build Your Own based on Certified Components.” tıklayın, sonrasında uyumluluğunu kontrol etmek istediğiniz ürünün modelini yazın, bu şekilde kolaylıkla uygun firmware ve driver versiyonunu bulabilirsiniz.

Data kaybına veya servis kesintisine uğramamak adına acil aksiyon almanızı tavsiye ederim.

Bu gibi konularda her zaman bana destek olan VMware TR ve HPE TR ekibine de iş birliktelikleri için ayrıca teşekkür ederim.

HPE SPP – Mayıs 2019

Öne Çıkan

Etiketler

, , ,


HPE, Mayıs ayı başında birçok yeni firmware ve driver paketi içeren Gen9/Gen10 sunucular için yeni bir SPP yayınladı. Nisan ayında yayınlanan SPP yi de geri cekti. Bu SPP özellikle IT altyapı biriminde calisan server yöneticisi tüm arkadaşların göz atması gereken bir pakettir. Özellikle de BIOS/SmartArrayController ve NIC firmware- driver paketlerini incelemenizi tavsiye ederim. Beklenmedik hizmet kesintilerinin önüne geçebilmek için, ben bu SPP paketini kendi ortamımda bulunan test sunucularıma geçtim, bir haftadır izliyorum. Eğer bir sorun yoksa yakında canlı sistemlere de geçeceğim.

Eğer ortamınızda VMware VSAN kullanıyorsanız ve bu storage servisini HPE Synergy sunucuları üzerinde çalıştırıyorsanız, Smart Array Controller firmware ve driver versiyonunuza çok dikkat etmeniz gerekmektedir. Nedeni, aşağıdaki HPE Advisory de açıklanmaktadır.

Benim önerim HPE sunucularınızda beklenmedik hizmet kesintilerinden kaçınmak için en azından yayınlanan bu bundle paketine bir göz atmanızdır.

HPE_SPP_Link

Smart Array Controller – Link

BIOS – Link

NIC – Link

Not: HPE Synergy SPP is published in different repository. Its is link.

VMware Skyline – Root Parolasının Yenilenmesi

Öne Çıkan

Etiketler

,

VMware Skyline uygulamasında appliance yönetim arayüzüne root ile erişiyorsunuz, buradaki parolayı unutursanız, uygulamaya erişimde değil ama appliance yönetiminde sorun yaşayabilirsiniz. Uygulama yönetimini admin account ile yaptığınız için o tarafta bir sorun yok. Root parolasının yenilenmesi ile ilgili VMware kısa bir KB yayınladı. Ancak ben biraz daha görsel hale getirip size sunmak istedim.

Sorunu aşağıdaki ekran daha güzel özetlemektedir.

Login:     https://vmware_skyline_server:5480

Username: root

Password: Unutuldu!

Çözüm:

  • Skyline sanal sunucusunu kapatın.
  • Makine kapandıktan sonra VM Remote Console ile vSphere Client üzerinden makineye erişin ve makineyi açın. Bu aşamada hızlı hareket etmelisiniz, çünkü Skyline küçük bir sanal sunucu olduğu için çok hızlı açılmaktadır.

  • Karşınızda Photon yazan grafik ekranı görünce hemen klavyede “e” tuşuna basın ve boot komutlarını gösteren ekrana geçeceksiniz.

  • Boot komutunun sonuna aşağıdaki komutu ekleyin ve F10 tuşuna basın.

    rw init=/bin/bash

  • Yaptığınız değişikliğin kalıcı olacağı Shell ekranına geçeceksiniz. “passwd” komutu çalıştırın ve parolayı değiştirin.
  • “reboot –f” ile makineyi reboot edin. Açıldıktan sonra kısa bir müddet bekleyin ve sonra admin ekranından appliance a login olmayı deneyin. Sorun çözülmüş olacaktır.

Source:
VMware KB 52652

Not: Bu arada Skyline sanal sunucusuna SSH ile erişmeyi denemeyin, çünkü SSH erişimine default kapalıdır.

vCenter 6.7 U2 – SMB ile vCenter Konfigurasyon Yedeklemesi

Öne Çıkan

Etiketler

Yeni Update 2 paketi ile gelen SMB protokol ile file paylaşımına yedek alınması gerçekten çok iyi oldu, önceki versiyonlar da vCenter konfigürasyonunu yedeklemek biraz eziyetti. Protokol kısmında verileri çok dikkatli girmen gerekiyordu. Hani bir deyimimiz var ya “Havadan nem kapmak” aynen o şekilde en ufak bir virgül, noktalama hatasında zamanlanmış backup job çalışmıyordu. Neyse yeni versiyon da bu kolaylık sağlanmış, kısa sürede backup job konfigürasyonunu yaptım ve çalıştırdım. Yedeği ortamımda bulunan bir fileshare e kolayca export ettim.

Backup job oluştururken aşağıdaki birkaç uyarıyı dikkate almanızda fayda var:

  • Backup location yazımı :

    smb://file_server_fqdn/folder1

  • User name: direkt klasöre yazma yetkisi olan kullanıcıyı yazın. Başına domain eklerseniz, çalışmıyor. Örnek tolga@company.net domain de yetkili kullanıcı. Buraya sadece “tolga” yazın yeterli. “Company\tolga” yazdığınızda ya da direkt UPN olarak “tolga@company.net” yazdığınızda job çalışmayacaktır. Burası önemli.

Kullanıcı adının yazımıyla ilgili sorunun detaylı analizi başka bir blog ta anlatılmaktadır. Link

Backup job çıktısı aşağıdadır.

VSAN Witness Host – Update Manager Tarama Sorunu

Öne Çıkan

Etiketler

, , , ,

Son zamanlarda başınıza hiç geldi mi bilmiyorum ama VMware VSAN için Witnes host u deploy ettikten sonra vSphere Update Manager (VUM) ile host u update etmek istediğinizde, daha ilk aşamada “scan” takılabiliyorsunuz.

Kurulum bitti, herşey yolunda. Bir ay sonra bir VUM ile gelen update leri kontrol etmek istedim, sonuçta witness ta bir ESXi host ve içinde ESXi OS var ama olmadı. Aşağıdaki hatayı aldım.

Sonra aşağıdaki VMware KB sini uyguladım, sonuç değişmedi.

Link: https://kb.vmware.com/s/article/59470

Witness host ta SSH servisi aktif ettim, WinSCP ile bağlandım.

/var/log klasörü altında bulunan “esxupdate.log” dosyası download ettim ve incelemeye başlar başlamaz aşağıdaki hatayı farkettim. Burada bir paketten dolayı bu tarama işleminde hata aldığını söylüyordu.

esxupdate: ERROR: ValueError: VIBs ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03 and ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03 have unequal values of the ‘payloads’ attribute: ‘[elx-esx-libelxi: 1602.936 KB]’ != ‘[elx-esx-libelxi: 1493.833 KB]

Log ta artık sorunu bulmuştum, Witness host ta bağlanıp işlem yapmadan önce ne olur ne olmaz witness appliance ının bir snapshot ını aldım.

[root@witnessesxihost:~] esxcli software vib list | grep ELX

    elx-esx-libelxima.so
12.0.1108.0-03 ELX VMwareCertified 2019-03-22

    [root@ witnessesxihost:~] esxcli software vib remove -n elx-esx-libelxima.so

    Removal Result

     Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

     Reboot Required: true

     VIBs Installed:

     VIBs Removed: ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03

     VIBs Skipped:

    [root@ witnessesxihost:~]reboot

Sonra shh servisi üzerinden putty ile Witness hosta bağlandım. Öncelikle vib paketini sorguladım. Sonra bu paketi makineden yukarıdaki komut ile kaldırdım.

Sunucuyu reboot ettim. Tekrar Update manager da scan işlemini başlattım ve mutlu son. Sorun çözüldü.

Bekleyen VMware patch lerini Witness host a yükledim.

Patchleri yükledikten sonra VSAN enabled cluster üzerinde yine de bir health check yaptım, herşey sorunsuz görünüyordu.

En son aşamada Witness appliance ta aldığım VMware Snapshot ı da kaldırdım.

Kullandığım ürünlerin versiyonları da aşağıdadır.

vCenter: 6.7 U1

VSAN: 6.7 U1

ESXi 6.7 U1

Bu sorunu da bu şekilde çözmüş olduk.

vSphere HA agent error “The object ‘vim.Datastore:datastore-XXX’ has already been deleted or has not been completely created”

Öne Çıkan

Canlı makineleri taşıyan cluster da bir tane ESXi host u reboot ettim ve aşağıdaki sorun ile karşılaştım. Host un üzerindeki vSphere HA servisi hata vermeye başladı.

The object ‘vim.Datastore:datastore-9497’ has already been deleted or has not been completely created

    Task name    : Reconfigure vSphere HA host

    Target        : EsxiHost

    Event log    : vSphere HA agent for host EsxiHost has an error in Cluster in DataCenter: vSphere HA agent cannot be installed or configured

  • Host un üzerinde sağ tıklayıp “Reconfigure for vSphere HA” komutunu çalıştırdım, olmadı.
  • Host u reboot ettim, olmadı.
  • Cluster seviyesinde vSphere HA disabled – enable ettim, olmadı. Bu sefer cluster içerisinde diğer tüm host larda aynı hatayı vermeye başladı. Başıma daha büyük bela açıldı.
  • VMware PowerClI ile vCenter a bağlanıp, aşağıdaki komut ile bu datastore un hangisi olduğunu bulmaya çalıştım. Fakat hata veren datastore cluster da yoktu. Muhtemelen bir müddet önce sildim, ve bugüne kadar da host lara dokunmadığım için bu hata oluşmamıştı.

Get-Cluster $cluster | Get-Datastore | Select Name, ID | Sort ID

  • vSphere HA ayarlarında 3.opsiyonu seçtim ve iki datastore seçip, HA yi cluster da tekrar disable – enable yaptım, yine olmadı.

  • ESXi host vmkernel / hostd / fdm loglarını da inceledim, bir sonuç çıkartmadım. FMD log ta gördiğim hata aşağıdadır.

    2019-04-15T06:29:40.689Z error fdm[86409] [Originator@6876 sub=Vmomi opID=2602764b] Caught exception while sending activation result: N5Vmomi5Fault11SystemError9ExceptionE(Fault cause: vmodl.fault.SystemError –> )

Kısaca ortam bilgisi de paylaşayım:

ESxi host version    : VMware ESXi, 6.5.0, 10884925

Total ESXi host in cluster: 8

vCenter Server version    : 6.7 U1

Type            : vCenter Virtual Appliance

Çözüm; biraz komik gelebilir. vCenter reboot.

vCenter sunucusunu yeniden başlattım ve sorun düzeldi. Bazen sorunla uğraşırken çok derine inebiliyoruz. Tabi bunun bizim ürün bilgimizi arttırmasında yararı var ama keşke en başta vCenter sunucusunu reboot etseydim dedim kendi kendime. Neyse sağlık olsun, sorun çözüldü ya önemli olan sonuç.

ESXi Driver Downgrade and Version Check

Öne Çıkan

Etiketler

,

Birçoğumuza göre basit bir işlem olabilir, ama benim yaptığım gibi full path vermezseniz, yok yere bir saatinizi harcayacağınız bir soruna dönüşebilen ESXi host üzerinde driver versiyonu düşürme işlemi, doğru driver versiyonu ile aşağıdaki adımlar takip edildiğinde aslında kısa süren bir işlemdir.

  • Öncelikle VMware Compatibility web sitesinden uyumluluk kontrolünü yapın. Bunun sonucunda çalıştırmak istediğiniz ortam için doğru driver versiyonunun hangisi olduğunu netleştirin.

    Link: VMware Compatibility Guide

  • VMware websitesinden doğru driver versiyonunu indirin. Driver paketleri üretici websitelerinden de indirilip, yüklenebilir ama VMware tarafından sağlanan versiyon test edilmiş bir versiyondur. VMware den indirdiğiniz zip paketini açın, içerisinden vib ve offline bundle dosyaları çıkacaktır.

  • ESXi host üzerinde SSH servisini aktif edin.

  • WinSCP gibi küçük bir tool aracılığıyla offline bundle paketini ESXi host ‚ta “/var/tmp ” dizinine upload edin.
  • Putty ile ESXi sunucusuna bağlanın.
  • “cd /var/tmp” komutuyla ilgili dizine gidin.
  • “ls –l ile bu dizindeki dosyaları detaylarıyla birlikte listeleyin. Komutun çıktısı aşağıdaki gibidir.

    [root@esxihost:/vmfs/volumes/89v6782-675fv678-44gv-1402ec8a8304/var/tmp] ls -l

    total 292

    -rwx—— 1 root root 148838 Apr 3 2018 VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip

    -rwx—— 1 root root 38 Apr 8 10:06 sfcb_cache.txt

  • Aşağıdaki komutu çalıştırıp, sizin upload ettiğiniz driver versiyonunu yükleyin.

    [root@esxihost:/vmfs/volumes/89v6782-675fv678-44gv-1402ec8a8304/var/tmp] esxcli software vib install -d /var/tmp/VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip

    Installation Result

    Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

    Reboot Required: true

    VIBs Installed: Microsemi_bootbank_nhpsa_2.0.30-1OEM.670.0.0.7535516

    VIBs Removed: Microsemi_bootbank_nhpsa_2.0.38-1OEM.670.0.0.8169922

    VIBs Skipped:

  • Sonuç komut çıktısında da göründüğü gibi başarılı, ancak yüklediğiniz driver versiyonunun geçerli olması için sunucunun reboot edilmesi gerekiyor. Öncelikle sunucunun üzerinde aktif VM varsa onları başka hostların üzerine taşıyın ve sunucuyu reboot edin.
  • Sunucu açıldıktan sonra aşağıdaki komutlarla driver versiyonumu kontrol edebilirim.

    esxcli storage core adapter list

    esxi software vib list | grep npsha

Bu bir network kartı olsaydı driver versiyonunu control edeceğim komutlar farklı olurdu.

esxcli network nic list

esxcli network nic get -n vmnic1

Işlem bu kadar basit. Yukarıdaki işlemde ben smart array controller kartın driver ını istediğim versiyona downgrade ettim. Aynı işlemi HBA veya NIC kartları yada diğer modüller içinde yapabilirsiniz.

Bu işlemde tek dikkat etmeniz gereken ayrıntı yükleme yaparken driver paketinin full path (tam dosya yolu) olarak vermenizdir. Yoksa aşağıdaki gibi hata alıyorsunuz.

[root@esxihost:/vmfs/volumes/89v6782-675fv678-44gv-1402ec8a8304/var/tmp] esxcli software vib install -d VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip

[MetadataDownloadError]

Could not download from depot at zip:/var/log/vmware/VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip?index.xml, skipping ((‘zip:/var/log/vmware/VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip?index.xml’, ”, “Error extracting index.xml from /var/log/vmware/VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip: [Errno 2] No such file or directory: ‘/var/log/vmware/VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip'”))

url = zip:/var/log/vmware/VMW-ESX-6.7.0-nhpsa-2.0.30-offline_bundle-8167186.zip?index.xml

Please refer to the log file for more details.

vCenter Upgrade – vSphere Web Client Failed!

Öne Çıkan

Etiketler

, , ,

vCenter appliance kullanıyorum ve kısa bir süre önce 6.5 U2c versiyonuna update ettim. Update ettikten sonra tüm servisler aktif oldu, fakat vSphere Web Client (Flash) servisi bir türlü çalışmadı. İlk başta hepimizin yaptığı gibi sunucuyu komple kapattım, yeniden başlattım. Sonuç aynı. Servisi manuel çalıştırmak için aşağıdaki komutu denedim, sonuç aynı. Aldığım hatayı da aşağıdaki görebilirsiniz. Bu arada HTML5 client sorunsuz açılmıştı.

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http16LocalServiceSpecE:0x00007feecc0203d0]_serverNamespace=/vpshere-client action=Allow_port=9090)

  • Web browser da Flash client a erişmeye çalıştığımda yukarıdaki hata ile karşılaşıyordum.

************************************************************************

root@vcenter [ /usr/lib/vmware-virgo/server/plugins ]# service-control –status –all

Running:

applmgmt lwsmd pschealth vmafdd vmcad vmdird vmdnsd vmonapi vmware-cis-license vmware-cm vmware-content-library vmware-eam vmware-perfcharts vmware-psc-client vmware-rhttpproxy vmware-sca vmware-sps vmware-statsmonitor vmware-sts-idmd vmware-stsd vmware-updatemgr vmware-vapi-endpoint vmware-vmon vmware-vpostgres vmware-vpxd vmware-vpxd-svcs vmware-vsan-health vmware-vsm vsphere-ui

Stopped:

vmcam vmware-imagebuilder vmware-mbcs vmware-netdumper vmware-rbd-watchdog vmware-vcha vsphere-client

************************************************************************

root@vcenter [ /usr/lib/vmware-virgo/server/plugins ]# service-control –start vsphere-client

Perform start operation. vmon_profile=None, svc_names=[‘vsphere-client’], include_coreossvcs=False, include_leafossvcs=False

2018-11-03T17:23:41.052Z Service vsphere-client state STOPPED

Error executing start on service vsphere-client. Details {

“resolution”: null,

“detail”: [

{

“args”: [

“vsphere-client”

],

“id”: “install.ciscommon.service.failstart”,

“localized”: “An error occurred while starting service ‘vsphere-client'”,

“translatable”: “An error occurred while starting service ‘%(0)s'”

}

],

“componentKey”: null,

“problemId”: null

}

Service-control failed. Error {

“resolution”: null,

“detail”: [

{

“args”: [

“vsphere-client”

],

“id”: “install.ciscommon.service.failstart”,

“localized”: “An error occurred while starting service ‘vsphere-client'”,

“translatable”: “An error occurred while starting service ‘%(0)s'”

}

],

“componentKey”: null,

“problemId”: null

}

************************************************************************

  • Log dosyalarına baktım, ilk bakışta pek bir şey çıkartamadım. Sonrasında bilgilerine çok güvendiğim ve her zaman sorunumu çözmem de bana destek olan VMware Türkiye ekibine case açtım ve sorunu analiz etmeye başladık.

************************************************************************

root@vcenter [ /var/log/vmware/vpxd ]# ls -l

root@vcenter [ /var/log/vmware/vpxd ]# grep warning vpxd-301.log (vpdx file numarası sizde değişik olabilir)

[ /var/log/vmware/vsphere-client ]# ls –l

root@ vcenter [ /var/log/vmware/vsphere-client ]# grep error vsphere-client-gc.log.0.current

root@ vcenter [ /var/log/vmware/vsphere-client/logs ]# less eventlog.log

root@ vcenter [ /var/log/vmware/vsphere-client/logs ]# grep WARN eventlog.log

root@ vcenter [ /var/log/vmware/vsphere-client/logs ]# cd /usr/lib/vmware-vsphere-client/server/

root@ vcenter [ /usr/lib/vmware-vsphere-client/server ]# cd work

root@ vcenter [ /usr/lib/vmware-vsphere-client/server/work ]# ls –l

root@ vcenter [ /usr/lib/vmware-vsphere-client/server/work ]# cat 1541273327676.log (en son veri yazılan log dosyası)

************************************************************************

  • Yukarıdaki komutları çalıştırıp sorunu araştırırken en son komutun çıktısında aşağıdaki hata loglarını gördük.

************************************************************************

!ENTRY org.eclipse.equinox.ds 4 0 2018-11-03 22:28:50.723

!MESSAGE [SCR] Unexpected exception occurred!

!STACK 0

java.lang.IllegalStateException: BundleContext is no longer valid

at org.eclipse.osgi.framework.internal.core.BundleContextImpl.checkValid(BundleContextImpl.java:931)

at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getServiceReferences(BundleContextImpl.java:498)

at org.eclipse.equinox.internal.ds.Reference.hasProviders(Reference.java:127)

at org.eclipse.equinox.internal.ds.Resolver.selectNewlyUnsatisfied(Resolver.java:600)

at org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:364)

at org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)

at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)

at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)

at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)

at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)

…………………..

at java.lang.Thread.run(Thread.java:748)

!ENTRY org.eclipse.equinox.ds 4 0 2018-11-03 22:28:50.724

!MESSAGE [SCR] Unexpected exception occurred!

!STACK 0

java.lang.IllegalStateException: BundleContext is no longer valid

………………..

************************************************************************

  • Yukarıdaki log çıktısından hareketle JAVA dosyalarının corrupt (bozuk) olduğunu düşündük ve log dosyasındaki Java component ini internetten indirip vCenter içerisine (aşağıdaki komutla conf dosyasında paketin bulunduğu yeri tespit edip) upload ettik. Sonra tekrar vsphere-client servisini çalıştırmayı denedik, sonuç yine aynı. Servis çalışmıyor.

    Not: Elinizde vCenter ın update öncesi hali varsa bu paketi backup tan da alabilirsiniz.

************************************************************************

root@ vcenter [ /usr/lib/vmware-vsphere-client/server/wrapper/conf ]# cat wrapper.conf

root@ vcenter [ /usr/lib/vmware-vsphere-client/server/wrapper/conf ]# cd /usr/lib/vmware-vsphere-client/server

root@vcenter [ /usr/lib/vmware-vsphere-client/server ]# mv work work_tlg Sorunun çözümü!

root@s152m0000015 [ /usr/lib/vmware-vsphere-client/server ]# ls -l

total 676

drwxr-x— 6 vsphere-client root 4096 Nov 2 13:45 configuration

-rwxr—– 1 vsphere-client root 664740 Aug 6 12:58 open_source_licenses.txt

drwxr-x— 2 vsphere-client users 4096 Nov 2 12:54 pickup

drwxr-x— 3 vsphere-client root 4096 Oct 9 2017 repository

drwxr-xr-x 6 vsphere-client users 4096 Nov 3 22:51 work_tlg

drwxr-x— 5 vsphere-client root 4096 Oct 9 2017 wrapper

************************************************************************

  • Biraz mola verdikten sonra tekrar sorunu internette araştırmaya devam ettim, bu arada farklı vCenter versiyonlarında benzer yaşanan bir sorunu adresleyen bir KB gözüme çarptı. Link aşağıdadır. Bu KB içerisinde bahsedildiği gibi cache bilgilerini tutan “work” klasörünü rename etmem öneriliyordu ve söyleneni yaptım.
  • Sonra vpshere-client servisini tekrar çalıştırmayı denedim ve sonuç “service started”.

************************************************************************

root@ vcenter [ /usr/lib/vmware-vsphere-client/server ]# service-control –start vsphere-client

Perform start operation. vmon_profile=None, svc_names=[‘vsphere-client’], include_coreossvcs=False, include_leafossvcs=False

2018-11-03T19:55:04.409Z Service vsphere-client state STOPPED

Successfully started service vsphere-client

************************************************************************

Çözüm : https://kb.vmware.com/s/article/2150318

Atalarımız ne demiş “Arayan mevlasını da bulur, Belasını da!” Biz log dosyalarının içine baktık, aldığımız bazı aksiyonlarla tüm vCenter ı patlatabilirdik ya da ayağa kaldırabilirdik. Biz doğru log dosyasından araştırmaya devam edip, çözüme ulaştık. Ancak komple vCenter ı da indirebilirdik, dolayısıyla bu tip işler öncesi kesinlikle backup alın, hatta bir değişiklik yapmadan elinizde vCenter ın da bir snapshot ı olsun.

Bu arada her zaman ekip arkadaşım gibi gördüğüm VMware Türkiye Support Ekibi, size de teşekkürler.

HPE OneView Global Dashboard (Linux) – Domain and Certification Issue

Öne Çıkan

Etiketler

, , ,


HPE OneView, altyapınızdaki HPE ürünlerini tek bir ekrandan yönetmenizi ve izlememizi sağlayan “software defined infrastructure” (yazılım tabanlı altyapı) mimarisini bize sunan bir HPE ürünüdür. HPE OneView Global Dashboard ise ortamınızda bulunan birden fazla HPE OneView ürününü tek bir ekranda toplayıp size tek bir sayfada ortamınızı izleme imaknı sunmaktadır.

Global Dashboard appliance OVF template olarak HPE websitesinden indirebilir. Ortamınıza deploy etmenizde 10 dakikalık bir işlemdir. Sonrasında bunu sanal sunucuyu domain’e ekleyip yetkilendirdiğiniz kullanıcı grubunun üyelerinin sadece bu sisteme giriş yapmasını ve lokal admin kullanıcısının (administrator) kullanılmamasını isteyebilirsiniz. Bu aşamada inanın benim gibi çok uğraşabilirsiniz. Global Dashboard un domain e üye yapılması sırasında aslında çok basittir. Belki siz kendi ortamınızda bu sorunu hiç yaşamayıp, tek adımda normal “Add Directory” ekranından domain bilgilerinizi girerek, sunucuyu domain’e üye yapacaksınız. Ama yine de belki benim gibi sorun yaşayanlar olabilir düşüncesiyle aşağıdaki adımları paylaşmak istedim.

HPE OneView Global Dashboard ürününüzü VMware virtual appliance olarak ortama deploy ettiniz ve lokal admin kullanıcısı ile network ten web sayfası karşınıza geliyor. Buraya kadar herşey ok, network ayarlarınızda (DNS, hostname, ping, IP, vs) düzgün. Makineyi domain ‘e dahil edelim dediniz. İşte bu noktada ben aşağıdaki hatayı aldım ve çok basit olan bu işlem bana birkaç güne mal oldu. Hatta HPE ye de Case açtım ve sorunun ana nedenini bulmaya çalıştım. HPE mühendisleriyle de sorunu analiz ettik, testler yaptık. Sonuçta aşağıdaki birkaç adımla sorun çözüldü.

Sol tarafta settings kısmından gidip Active Directory ile ilgili gerekli tüm bilgileri girip OK tuşuna basınca yukarıdaki ekranda sağ tarafta gördüğünüz hatayı alıyordum.

“One or more certificates in the chain may not have been added to the appliance or can not be trusted.”

Çözüm olarak ise CA sertifikalarınının appliance trust store içerisine eklenip eklenmediğini ve geçerliliklerini kontrol etmem öneriliyordu.

“Check if required CA certificates have been added to the appliance trust store and are valid”

Öneri doğruydu fakat yeterli değildi. Lafı çok uzatmayalım, nasıl çözdük?

  • Mevcut domain’e zaten üye olan Windows yüklü bilgisayarımda (laptop) MMC çalıştırdım ve “Certificates” snap-in ini “Computer Account” olarak ekledim.

  • Intermediate Certification Authorities kısmına geçtim.

 

  • Bu alanda Root ve ona bağlı Intermediate sertfikasını “Base-64” formatında export ettim.

  • Yine aynı ekranda root ve Intermediate sertifikalarını cift tıklayıp, CRL linklerini buldum ve verilen adrese Internet Explorer ile gidip, bu CRL (Certificate Revocation List) dosyalarını da her iki sertifika için ayrı ayrı download ettim. Bu adım çok önemli. CRL dosyaları olmadan işlem tamamlanmış olmuyor.

  • Sonra bu sertifikaları HPE OneView Certificate Trust Store içerisine gidip ekledim. Sertifikaları Notepad ile açıp içerisindeki kodu da direkt verebilirsiniz.
  • Root ve Intermediate sertifiklarını ekledikten sonra birkaç dakika bekleyin. Çünkü ilk eklediğinizde yeşil (OK) durumda olan sertifikalar, CRL bilgisi olmadığı için sonrasında sarı (warning) hale dönecektir.
  • Birkaç dakika bekledikten ve ekranı yeniledikten sonra yine aynı sertifikaları seçip, sağ tarafta açılan ekranda “Upload CRL” butonuna basıp, her iki sertifika için de CRL dosyalarını ekledim.
  • Son olarakta yine en başa dönüp, makineyi domain e ekleme adımından domain üyeliğini gerçekletirdim ve sorun çözüldü.

Yukarıdaki çözüm yöntemi aslında sadece OneView için geçerli değil, birçok Linux makinede de işinize yarayabilir. Her zaman Linux tabanlı bir makineyi domain e eklemek bu şekilde sıkıntı olmaz, ama yine de bu bilgiler elinizin altında bulunsun.

vCenter 6.7U1 – Veeam Backup First Issue (Solved)

Öne Çıkan

Etiketler

Geçtiğimiz hafta yayınlanan vCenter 6.7 U1 ile ilgili ilk gördüğüm sorunu ve Veeam KB sini sizinle paylaşmak istedim. Ben henüz denemedim ama test ortamınızı veya henüz erken olmasına rağmen canlı ortamınızı vSphere 6.7 U1 update ederseniz, Veeam ile backup alırken şimdilik karşınıza ilk olarak aşağıdaki hata geliyormuş.

“Object reference not set to an instance of an object”

Dolayısıyla backup alamıyorsunuz ama korkulacak bir hata değil, çünkü Veeam konuyla ilgili hemen bir workaround içeren KB yayınlamış.

Link : https://www.veeam.com/kb2784

Yakın zamanda Veeam Update 4 paketini yayınlayacak ve bu sorunu kalıcı olarak çözülecek. Çünkü Update 4 paketi vSphere 6.7 U1 versiyonunu da resmi olarak destekleyecek. Veeam bunun bilgisini KB içerisinde paylaşıyor.

Herkese iyi haftalar!

High KAVg Value for IOPs limited VM (disable mclock)

Öne Çıkan

Etiketler

, , , ,

Geçenlerde disk basina IOPs limit uyguladığımız yüksek IO üreten sanal makinelerde vSphere 6.5 upgrade sonrası performans sorunu gözlemledik. Sorunu analiz ettik, fakat bir yere varamadık, çünkü yaptığımız tüm konfigürasyon normal görünüyordu. ESXi host larımızda IO paket size 64 KB olarak set edilmişti. VMware, NetApp için gerekli uyumluluk ayarları yapılmıştı. (Best Practices). Sunucu (HBA, BIOS,vs) firmware – driver yazılımları günceldi. Ancak esxtop ile baktığımızda yüksek Kernel latency gorunuyordu.

En sonunda VMware Support ekibine sorunu bildirdik, yapılan analiz sonucunda sorunun vSphere 5.5 ile birlikte gelen mclock I/O scheduler dan kaynaklandığını tespit ettik. Mclock özelliğini kapatıp, daha önceden kullanılan default I/O scheduler a geçtik ve I/O intensive olan buyuk SAP database ler çalıştıran VM lerde sorun bir anda düzeldi. KAVg değerleri normale döndü.

Mclock I/O Scheduler ı kapatıp, default I/O scheduler a geçmek için aşağıdaki adımları takip etmelisiniz:

  • ESXi host a SSH üzerinden putty ile bağlanın.
  • Komutu çalıştırın.

    esxcli system settings advanced list -o /Disk/SchedulerWithReservation

  • Int Value :1 değeri mclock özelliğinin açık olduğunu gösteriyor.

Path: /Disk/SchedulerWithReservation

     Type: integer

     Int Value: 1

     Default Int Value: 1

     Min Value: 0

     Max Value: 1

     String Value:

     Default String Value:

     Valid Characters:

     Description: Disk IO scheduler (0:default 1:mclock)

  • Mclock kapatmak için aşağıdaki komutu çalıştırın. ESXi host u reboot etmenize gerek yok. Hatta VM ler çalışırken de bu değişikliği yaptık ve bir sorun olmadı.

esxcli system settings advanced set -o /Disk/SchedulerWithReservation -i=0

Mclock özelliğini kapatıp, default I/O scheduler ‘ı aktif ettikten sonra IOPs limit uyguladığınız VM lerde performansın bir anda düzeldiğini göreceksiniz. Sonucu esxtop ile host seviyesinde de KAVg değerinin düştüğünü gözlemleyip, teyit edebilirsiniz.

Herkesin ortamında bu sorun olacak diye bir şey yok, çünkü ortamlarımız, kullandığımız donanımlar, yaptığımız ayarlar farklılıklar gösterebilir. Benim ortamımda yaşanılan sorunu yukarıdaki şekilde çözdük, umarım sizin de işinize yarar.

Join vCenter Appliance to Active Directory

Öne Çıkan

vCenter 6.5 veya üstü appliance deploy ettikten sonra onu domain ‘e eklemek istediğinizde belki benim gibi biraz sorun yaşayabilirsiniz.

Bu konuda biraz zaman harcamış olsam da sonunda sorunsuz bir şekilde vCenter appliance ‘ını domain e eklemeyi başardım, bu ufak tecrübeyi de sizinle paylaşmak istedim.

OU kısmı ve kullanıcı adının yazım şekli çok önemli, yazım standartına uyarsanız, bu basit adımı hızlıca geçebilirsiniz.

Domain: xxx.yyy.net –> buraya domain adınızı yazın.
OU: OU=aaa,OU=bbb,DC=xxx,DC=yyy,DC=net –> Bu kısımda vCenter computer objesinin konumlandıracaginiz OU nun tam DN adresini yazın.
Username: tolga@xxx.yyy.net –>Domain de yetkili bir kullanıcıyı buraya yazın. Yazım şekline dikkat edin.