Sahip olduğumuz donanımın ve sistemlerimiz için gerekli kaynakların ne kadar güçlü olduğuna bağlı olarak, sunucu başına ortalama bir sanal makine oranına sahip olacağız.
Örneğin, Bilgisayar Merkezi'ndeki bir sunucunun planlı bakımını ele alalım. Birkaç yıl önce, eğer bu bir kümenin parçası olmasaydı, ekipmanın içerdiği sistem çevrimdışına alınacaktı, dolayısıyla kullanıcılar da bundan etkilenecekti ve/veya bakıma dahil olan personel, daha kısa zaman aralıklarında çalışmak zorunda kalacaktı. rahatsız).
Sanallaştırılmış bir ortam söz konusu olduğunda, sanal makineler basitçe bir kümenin başka bir üyesine "taşınabilir veya geçirilebilir" ve ekipman üzerinde çalışmak üzere kapatılabilir. Sorun çözüldü.
Hizmet eksikliğinin programlanmadığı durumları görmeye başlayalım.
Sanal makine ve uygulama izleme
Her sanal makine oluşturduğumuzda, sanal donanımın davranışını bütünüyle optimize eden bir uygulama ve sürücü özeti yüklememiz önerilir (Windows, Mac OS, Linux ve diğer işletim sistemleri için mevcuttur). VMTools adı verilen bu araçlar, diğer şeylerin yanı sıra, ana bilgisayarın sanal makineyi (kümelerde olduğu gibi kalp atışları aracılığıyla) izleme olasılığını içerir. Belirli bir süre içinde yanıt vermezse İşletim Sisteminizi yeniden başlatır.
Uygulama izlemede de benzer bir durum olur, ancak önce uygun SDK'yı edinmeniz (veya VMware Application Monitoring'i destekleyen bir uygulama kullanıyor olmanız) gerekir.
Ama … arıza donanımsa ne olur?
Yukarıda bahsedilen küme, çözümün ilk katmanıdır.
Paylaşılan depolama alanıKümenin tüm üyelerinin sanal makinelere erişimi olduğu yer.
Ağ ekibi oluşturmaBir panonun arızası ile karşı karşıya kalanlar, trafiği yönetmeye devam ediyor.
Birden çok yol (çok yollu)Depolama için yalnızca erişimi optimize etmekle kalmayacak, aynı zamanda artıklık da sağlayacaktır.
Genel olarak konuşursak, bu üç teknoloji, bilgilerimize erişilemediği zamanları azaltır. Artık sahip olduğumuz lisansa bağlı olarak iki çok ilginç özelliğimiz de olabilir: Yüksek Kullanılabilirlik (HA) ve Hata Toleransı (FT).
Her iki durumda da paylaşılan depolamaya sahip bir kümeye ihtiyacımız var. Ek yazılım yüklemeye gerek kalmadan HA etkinleştirilebilir ve kümede bir sunucu veya sanal makine arızalanırsa kümenin başka bir üyesinde otomatik olarak başlayacak şekilde yapılandırılabilir. HA'nın görev açısından kritik VM'ler (sanal makineler) için tasarlanmadığını açıklığa kavuşturmaya değer. Yani servissiz tahmini süre: "İşletim Sistemini Başlatma + Servisleri Başlatma" olacaktır.
Küme tarafından desteklenen ana bilgisayar hatası sayısı
Bir kümede Y sunucularına dağıtılmış X adet sanal makinemiz var.
Sanal ortamımızın kullanılabilirliğini ve performansını etkilemeden kaç ana bilgisayar başarısız olabilir?
HA, belirli sayıda sunucu hatasını destekleyecek şekilde yapılandırılabilir, böylece kurtarma işleminde yeterli kaynak kalması sağlanır.
HA, sanal makinelerimiz tarafından yapılandırılan ve tüketilen CPU ve RAM'i çok muhafazakar bir şekilde hesaba katarak bir kümenin kullanılabilir kaynaklarını dilimler. Kümedeki her ana bilgisayardaki herhangi bir VM'nin en büyük yapılandırılmış CPU rezervasyonunu ve ardından en büyük bellek rezervasyonunu ve fazlalığını alır. Konfigüre edilmiş bir rezervasyon yoksa, CPU için VM başına minimum 32 Mhz ve 0 Mb RAM + fazlalığı alacaktır.
Bu sayılarla, kullandığı her sanal makinenin o CPU ve belleği kullanacağını varsayar ve ardından yuva boyutu adı verilen bir değer üretir. Bu değer ile her bir host tarafından kaç adet slot kullanılabilir/kullanıldığı belirlenir.
Sorun, örneğin, büyük bir CPU ve bellek rezervine sahip tek bir makinemiz olduğunda ortaya çıkar. Yapılandırılmış rezervasyonları alarak, sanal makinelerimizin geri kalanının bu kaynaklara gerçekten ihtiyaç duymaması ve kümemiz için daha az yuvaya neden olması çok olasıdır.
Küme kaynaklarının yüzdesi başarısızlıklar için kapasite olarak
Önceki seçeneğin aksine, bu seçenek, çok değişken CPU ve bellek yapılandırmalarına sahip VM'leriniz olduğunda çok iyi çalışır.
CPU ve belleğin yüzde değerlerini ayrı ayrı konfigüre etmek mümkündür, bu şekilde daha da esnek olmak ve dolayısıyla kaynaklardan tasarruf etmek mümkündür. Bu genellikle HA'yı yapılandırmak için tercih edilen yöntemdir.
Yük devretme için ana bilgisayarlar
Bu, tipik bekleme kümesi yapılandırmasıdır. Bu seçenek esas olarak, bazı kuruluşlar herhangi bir felaket durumunda sunucuların beklemede olması gerektiğini belirten ilkelere sahip oldukları için verilir. VMware hata toleransı yönetimini iyi yaptığından, kaynaklar bol olduğunda bu seçenek olabilir… ama kesinlikle en iyisi değil.
vHareket: Canlı geçişler
Canlı geçiş, ağ bağlantınızı ve kimliğinizi korurken çalışan sanal makineleri bir fiziksel sunucudan diğerine taşımanıza olanak tanır. Aktif bellek (çalışan işlemler) yüksek hızlı ağ üzerinden aktarılır. Tüm süreç bir gigabit ağında 5 saniyeden az sürer.
VM'yi, kullandığı dosyaları veya her ikisini birden taşımak mümkündür ve işlem makine açık veya kapalıyken yapılabilir. İkinci durumda buna "soğuk göç" diyoruz ve makine çalışıyorsa buna vMotion diyoruz.
vMotion'ın kullanımları ve faydaları
- sanal makinenin yeniden düzenlenmesi, böylece kaynakları optimize eder. Bunları başarısızlığa meyilli veya doygun olan sunuculardan kaldırın.
- Mevcut kaynakların otomatik optimizasyonu (Dinamik Kaynak Zamanlayıcı veya DRS ile birlikte çalışıyorum).
- Yapmak temel altyapının bakımı bakım planlamasına veya iş kesintisine gerek yok.
VM sağlığının her bileşeni, geçiş sırasında farklı şekilde işlenir. Genel yapılandırma en basitidir, hareket etmez ancak hedef bilgisayarda yeniden oluşturulur.
Disk bu kadar kısa sürede yeniden oluşturulamadığından paylaşımlı depolamaya sahip olmak gerekir. Belleğin mevcut durumu kademeli olarak hedef ana bilgisayara kopyalanır.Kopyalama sonunda, geçiş sırasında ortaya çıkan mevcut farklılıklar karşılaştırılır, kaynak VM'nin durumu dondurulur ve hedef VM'de işletim sistemi etkinleştirilir. .
Bazı durumlarda makineyi yeniden başlatma seçeneği ideal olmadığından, kritik görevler için Hata Toleransı. Bu durumlarda istenen, ana bilgisayarı başarısız olsa bile hiçbir zaman çalışmayı bırakmaz. Bunun mümkün olmasının tek yolu, VM'nin aynı anda iki yerde çalışıyor olmasıdır. Sanal makine düzeyinde yapılandırılır ve VM'nin tam bir kopyasını oluşturarak her zaman başka bir sunucuda %100 kopyalanmasını sağlar. bir donanım arızası durumunda, ikizi herhangi bir bilgi kaybı olmadan çalışmaya devam edecektir. İlginç, değil mi?
Sadece kaynaklarla ilgili olsaydı, veri merkezimizdeki tüm sanal makinelerde FT'yi etkinleştirirdik, ancak vSphere'in önceki sürümlerinde bazı sınırlamalarla karşılaştık, en önemlisi: FT'yi birden fazla sanal kullanan makinelerde etkinleştirmek mümkün değildi. işlemci Neyse ki, ürünün en son sürümünde, korumalı makine başına aynı anda 4 adede kadar sanal işlemciyi destekler, ancak lisanslamanın dikkate alınması gerekir:
FT özellikli bir VM tarafından desteklenen vCPU sayısı, vSphere için satın alınan lisans düzeyiyle sınırlıdır.
Hata Toleransı aşağıdaki şekilde desteklenir:
- vSphere Standard ve Enterprise. 2 vCPU'ya kadar izin verir.
- vSphere Enterprise Plus. 4 adede kadar vCPU'ya izin verir.
Sistemin tek şartı bu değil.
DepolamakVM'lerin paylaşılan depolama alanı olmalıdır. Fiziksel RDM (Raw Devide Mapping) kullanmak mümkün değildir.
AğBiri vMotion, diğeri FT Logging için (10 gbps) olmak üzere en az iki sanal karta (vmnics) sahip olmak gerekir. Sürüm 6'nın yeni bir gereksinimidir (önceden 1 gbps plakalar gerekliydi)
İşlemciİşlemciler ve İşletim Sistemleri FT ile (ve birbirleriyle) uyumlu olmalıdır.
sınırlamalar
- FT ile korunan sanal makinelerin anlık görüntülerini almak mümkün değildir ve bu işlev etkinleştirilmeden önce silinmeleri gerekir.
- 2 Tb'den büyük sanal diskler (VMDK).
- VMware belgelerinde belirli aygıtların ve özelliklerin bir listesi vardır.
Ayrıca sunucu başına VM sayısında bir sınırlama vardır: ana bilgisayar başına maksimum 4 korumalı makine veya 8 korumalı vCPU (hangisi önce gelirse). Bu maksimum değerler, birincil ve ikincil makineyi (ve vCPU'ları) içerir.
FT mirası (önceki) ve mevcut arasındaki farklar
IPv6
Eski FT = FT günlüğü için yapılandırılmış ağ kartları tarafından desteklenmez FT = Desteklenir
Vstorage API'leri - Veri Korumalı Yedekleme
Eski FT = Desteklenmiyor FT = Destekleniyor
sanal disk
Legacy FT = EZT (Hevesli Sıfırlanmış Kalın) FT = Kalın ve ince dahil tüm türler
Vmdk yedekliliği (sanal disk)
Eski FT = Tek kopya FT = Birincil ve İkincil makineler bağımsız kopyalar tutar, bu onların farklı veri depolarında depolanmasına ve yedekliliği artırmalarına olanak tanır
Ağ plakası bant genişliği
Eski FT = Adanmış 1 Gb NIC önerilir FT = Adanmış 10-Gb NIC önerilir
CPU ve ana bilgisayar uyumluluğu
Legacy FT = Aynı CPU modelini ve ailesini gerektirir. Neredeyse aynı vSphere sürümleri FT = CPU'lar vSphere vMotion veya EVC ile uyumlu olmalıdır. VSphere sürümü, vSphere vMotion ile uyumlu olmalıdır
Makine çalışırken FT'yi Etkinleştir / Devre Dışı Bırak
Eski FT = Her zaman desteklenmez FT = Desteklenir
FT'nin işletim sistemleri veya uygulama arızalarına değil, sunucu donanım arızasına karşı koruma sağladığını unutmayın.
vCenter Sunucu Bekçisi 6.x sürümünün yerleşik bir işlevidir. vCenter'ı oluşturan servislerin durumunu periyodik olarak kontrol eder, gerekirse yönetim işlemlerini veya VM'yi yeniden başlatır.
