Başlangıç > VMware > 109: Service Console bağlantısını yedeklemek

109: Service Console bağlantısını yedeklemek

Service Console (SC) bağlantısı genelde iki amaç için kullanılır. Birincisi vCenter ilgili ESX sunucusu ile SC bağlantısı üzerinden iletişim kurar. İkincisi ve daha önemlisi ise, eğer HA kullanıyorsanız, ESX sunucular keni aralarında heartbeat paketlerini bu interface üzerinden gönderirler. Tehlike ise şurada, eğer bir ESX sunucusu diğer ESX sunucularından heartbeat paketi alamazsa ve kendi default gateway’ini de pingleyemezse, kendisinde bir sorun olduğunu düşünür ve HA tanımları içerisinde belirtilen “isolation response” u tetikler. Güncel versiyonda ise default isolation response “Shut Down” dır. Sonuçta bu şu anlama gelir, sadece SC bağlantınızda problem olması bile, o ESX üzerinde tüm sanal sunucularınızın HA prosedürü dahilinde başka bir ESX üzerinde yeniden başlatılmasına sebebiyet verebilir, yani eşittir downtime…

Bu tip false-positive durumları engellemek adına alabileceğimiz aksiyonlar var.  Öncelikle SC bağlantısını ethernet seviyesinde yedeklemek. Bunun için SC networküne bağlı iki adet uplink işimizi görecektir. Benim genelde kullanmayı tercih ettiğim konfigürasyon şu şekilde,

  • Bir vSwitch oluşturulur (vSwitch0). İki uplink tanımlanır (active/active, iki farklı fiziksel switche gidecek şekilde ve fiziksel switchlerin desteklediği varsayılarak).
  • İki portgroup tanımlanır, SC ve vMotion (her biri için ayrı yedekli uplinkler oluşturmak maliyetli olacağından, tek bir vSwitch içerisinde vMotion networkünü de aradan çıkartmak mantıklı).
  • Portgroup’lar için active/passive tanımlama yapılır (örnekte SC için aktif uplink vmnic0 iken vMotion için vmnic1 tanımlayabiliriz. Böylece her biri kendi uplinklerinden çalışırken, sadece failover durumunda ortak uplink kullanırlar).
  • Fiziksel switch üzerinde yapılabilecek muhtemel bir çalışma sonrasında “Spanning Tree” problemlerini engellemek için failback NO seçmekte fayda var.

Bu konfigürasyon bizi tek bir switch’in kapanması gibi durumlardan koruyacaktır.

Not: Aslında SC portlarını yedeklemediğimiz durumda, vCenter bizi uyaracak ve HA cluster üzerinde Redundancy hatası verecektir (KB).

Eğer imkanınız varsa, ikinci bir SC bağlantısı da yaratarak, subnet ve hatta fiziksel LAN seviyesinde de yedekleme yapabilirsiniz. Çok yakından tanıdığım bir altyapıda benzer bir ihtiyaç doğmuştu. SC bağlantısı Gigabit switch altyapısı üzerinden, VM trafiği ise 10G altyapı üzerinden akıyordu. Burada yapılacak en doğru hareket, 10G altyapısı üzerinde de bir SC yaratıp, riski neredeyse sıfıra indirmek. Böyle bir yapıda ancak ve ancak 4 switch üzerinde birden sorun olması durumunda ESX’ler isolation durumuna düşecekler.

Bunun için ilgili vSwitch/dvSwitch üzerinde SC için yeni bir portgroup yaratırız. Network tarafında bu portgroup için tanımlanan subnet’in primary SC ve hatta vCenter için tanımlanan subnetten farklı olması tavsiye edilir. Aksi taktirde VMkernel üzerinde ekstra routing tanımlamaları yapmak gerekebilir. SC tanımlandıktan sonra esxcfg-vswif -l komutu ile kontrol edebiliriz, aşağıdakine benzer bir çıktı elde ederiz:


Name    Port Group/DVPort  IP Family IP Address     Netmask       Broadcast     Enabled  TYPE
vswif0  Service Console    IPv4      10.10.1.21   255.255.255.0   10.10.1.255   true     STATIC
vswif1  3609               IPv4      10.10.2.21   255.255.255.0   10.10.2.255   true     STATIC

Bu noktada VMkernel routing tablosunu da kontrol etmekte fayda var. route komutu bize bu çıktıyı verecektir.


Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.2.0       *               255.255.255.0   U     0      0        0 vswif1
10.10.1.0       *               255.255.255.0   U     0      0        0 vswif0
169.254.0.0     *               255.255.0.0     U     0      0        0 vswif1
default         10.10.1.1       0.0.0.0         UG    0      0        0 vswif0

Bu tanımların geçerli olabilmesi için HA’yi disable/enable etmek gerekmektedir. Bu noktadan sonra yeni tanımlanan SC üzerinden heartbeat paketleri geçmeye başlayacaktır. Ancak halen bir eksik var. HA, eğer ESX sunucusu diğer ESX’lerden haber alamadığında default olarak sadece kendi gateway’ini pinglemeye çalışacaktır. Dolayısı ile, yeni tanımladığımız SC’nin subneti içerisinde bir IP adresini daha test etmesini sağlamak mantıklı olacaktır. Bunu HA tanımları içerisine bir advanced parametre girerek tanımlayabiliriz:

  • das.isolationaddress2 = 10.10.2.1 (ikinci subnet için her zaman pinglenebilir bir IP)

Böylelikle VMkernel’in gateway IP’si dışında ikinci bir IP ile de kontrol yapma şansımız olacaktır. Birden fazla isolation address tanımlandığı durumlarda da VMware’ın önerdiği bir best-practice daha var, o da “failure detection time” süresinin artırılması. Normalde 15 saniye olan bu değeri 20 saniye ya da üstüne ayarlanması gerekiyor. Bu süre kabaca şunu belirtiyor, eğer ESX sunucusu bu süre kadar bir zaman zarfında iletişim kuramazsa, kendini izole kabul ediyor ve isolation response tetikleniyor. Ben genelde 40 saniyeyi tercih ediyorum, çünkü 20 saniyelik bir gecikme diğer taraftan false-positive oranını ciddi oranda azaltacaktır, kesinlikle alınabilecek bir risk. İlgili advanced parametre:

  • das.failuredetectiontime = 40000 (milisaniye cinsinden)

Herkese isolation response’dan uzak bir hayat temennilerimle :)

Daha detaylı bilgiler için başvurabilirsiniz: KB, KB2

Kategoriler:VMware Etiketler:, ,
  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

w

Connecting to %s

%d blogcu bunu beğendi: