Daha önceki makalede Hyper-v yapılandırılmış iki adet sunucuda, herhangi bir önkoşula gerek kalmadan replicalar oluşturmuştuk. Bu sunucular için network haberleşmesi ve birbirlerinden gelen replikaları kabul etmelerini ayarlamak dışında herhangi bir önkoşula gerek yoktur. Özellikle domain üyesi olmaları gerekmemektedir. http://www.cozumpark.com/blogs/virtualization/archive/2013/02/10/hyper-v-3-0-replica-workgroup-ve-untrusted-domain-sertifika-ayarlar.aspx adresinden erişebileceğiniz Hüseyin Kartal’ın makalesindeki gibi yalnızca hyper-v rolü aktive edip birkaç ek ayarla SSL üzerinden replikasyon bile sağlayabilirsiniz.
Fakat günümüzün iş sürekliliği senaryolarında sunucuların yüksek erişilebilirliği önem kazanıyor, dolayısıyla sunucularımızın cluster yapılarda bulunması da olasıdır. Cluster mantığı da belirlenen görev veya sanal sunucuların, yine belirlenen nodelar üzerinde dolaşmasına dayanıyor.
Hyper-v replica ile ilgili makaleleri incelediğinizde herhangi bir sanal sunucu için kaynak sunucunuzda tanımlama yaparken hedef belirtmeniz dışında bir işlem yapmıyorsunuz. Peki ya kaynağınız veya hedefiniz cluster içerisindeki bir yüksek erişilebilir (HA) sanal sunucuysa? Kaynağınız oluşturduğunuz sırada A node iken herhangi bir sebeple B node taşındığı zaman replikasyon devam edebilir mi? Her node için ayrı ayrı replikasyonmu ayarlamalıyız?
Yukarıdaki sorulara cevap Hyper-v Replica broker rolü olarak dönüyor. Failover cluster management üzerinden cluster rolü olarak ekleyeceğiniz bu hizmet, kaynağınız veya hedefiniz bu cluster içerisindeki nodeları içeriyorsa, gerekli dağılımı kendisi yapıyor. Bunun için sadece broker için belirlediğiniz client acces point (CAP) replica site olarak tanımlamanız gerekiyor.
Cluster ortamı domain gerektirdiğinden, broker yapılandırdıktan sonra domain üyeleri üzerinden işlem yapıyor olmanız gerekiyor.
Aşağıda göreceğiniz gibi bir yapu hazırladım. Merkez üzerinde yapılandırdığım bir cluster var ve bunun üzerindeki sanal işletim sistemlerini HTTPS portu üzerinden yine domainle iletişime geçebilecek bir hyper-v hostuna replike etmek istiyorum. DC üzerinde işlem kolaylığı açısından bir de sertifika yetkilisi rolü (CA) bulunmaktadır.
Hyper-v replica site olarak kullanacağımız cluster yapısına role olarak hyper-v replica broker ekliyoruz. Bu işlem için Failover Cluster Manager üzerindeki roles seçiyoruz.
Her cluster rolü için belirlediğimiz gibi bir cluster access point (erişim noktası CAP) belirliyoruz.
Diğer aşamalarda bir özet görecek ve sonrasında rolümüzü hazır hale getireceğiz. İşlemin son aşamasında çıkan sonuç penceresinde yapılandırmayı hyper-v connection broker rolü üzerindeki replikasyon ayarlarıyla bitirmemiz gerektiği söyleniyor.
Artık işlemlerimize Failover Cluster Manager üzerindeki rolümüz üzerinde replication settings (replikasyon ayarları) menüsü ile devam edeceğiz.
CAP oluşturduktan hem hedef olarak belirtirken, hem de kaynak olarak belirtirken nodelarımızı tek tek replica ayarlarında belirlemek yerine CAP üzerinden işlemleri yapmalıyız. Aksi takdirde benim cluster yapısını oluşturmadan önce replikasyonunu ayarladığım sunucudaki gibi replikasyonunuzu devam ettiremeyecek ve aşağıdaki gibi bir hata alacaksınız.
Replikasyon yapılandırması tekil sunucular arasında yapılandan farklı özellikler veya menüler içermiyor. Replication settings içerisinde de bu sunucunun replica olarak kullanılabilmesini, işlemleri gerçekleştireceği portu, sertifika ve replikasyon yapılabilecek sunucuları belirliyoruz. Burada dikkat edilmesi gereken eğer HTTPs üzerinden erişim seçtiyseniz sertifika belirleme sırasında ortaya çıkacak hata mesajıdır.
CAP her ne kadar DNS ve AD users computers üzerinde bir kayda sahip olsa da daha önceki tekil sunuculardaki gibi direk olarak certificate authority (CA)ye erişip bir sertifika alamıyor. Bu işlemleri mmc ile certificates konsolunu açmanız halinde de maalesef çalışmıyor. Computer şablonu ile talep ettiğinizde hangi sunucudan sertifikayı talep ediyorsanız sertifika orası için geliyor, SAN ekleyemiyorsunuz, Web Server olarak talep ettiğinizde de sertifika yalnızca server authentication için geliyor. (daha önceki makalede sertifikaların içeriğinin nasıl olması gerektiğinden bahsetmiştik, zaten hata mesajında da görebileceğiniz gibi client ve server için kullanılabiliyor olması gerekiyor.)
Bu sorunu çözmek için isterseniz bir wildcard sertifika kullanabilir isterseniz aşağıdaki işlemleri uygulayabilirsiniz.
Öncelikle daha öncede söylediğim gibi sertifikayı computer şablonu ile almamız gerekiyor. Fakat bu şekilde talepte bulunduğumuzda hangi sunucu üzerinden talepte bulunduysak o sunucuya sertifika alabiliyoruz. Sorunu aşmak için CA üzerindeki şablonlarla biraz oynamamız gerekiyor. Sertifika şablonları kısmına gidip “manage (yönet)” ile yeni bir şablon oluşturacağız.
Computer şablonununun bir kopyasını oluşturuyoruz.
Seçenekler içerisinde server 2003 veya 2008 seçmenin çok bir önemi bulunmuyor. Ben 2003 seçerek devam ediyorum.
Şablon üzerinde değiştirmeniz ve dikkat etmeniz gereken yerlerden “general (genel)” sekmesindeki şablon ismini belirlemekten sonra (1) verilen sertifikanın geçerlilik süresini de uzun tutabilirsiniz. Çünkü 1 yıl olarak verilen varsayılan geçerlilik değeri bittiğinde sertifikayı bu metodla tekrar yenilemeniz gerekecektir. (2)
Domain ortamında çalışmalarımızı yaptığımızdan oluşturulan sertifikaların AD içerisinde dağıtılabilir olmasını sağlamalıyız. (3)
Şablondaki diğer önemli sekme “security (güvenlik)” sekmesidir. Bu sekmede broker için talepte bulunacağımız sunucunu enroll yetkisinin olup olmadığını kontrol etmeliyiz.
İşlemler ve kontroller bittikten sonra OK butonuyla şablonu kaydediyoruz. Bu şablonun CA tarafından kullanılabilir olması için yine Certificate authority konsolundan sertifika şablonlarına gelip, New>certificate template to issue (verilebilecek sertifika şablonu) yaparak şablonlar içerisinden CLS adı verdiğimiz şablonumuzu seçeceğiz.
Bu işlemden sonra CA dışındaki domain üyesi sunucularımızın biri (cluster node olması durumunda daha az işlem yapacaksınız) üzerinde bir sertifika talebi üreteceğiz. Aşağıda içeriğini göreceğiniz şekilde bir inf dosyası oluşturacağız. Ben bu inf dosyasını masaüstünde cert.inf şeklinde oluşturdum. İçeriğe bakarsanız subject name (SAN) olarak broker için belirlediğimiz CAP ismini ve sertifika şablonu olarak az önce oluşturduğumuz CLS şablonunu girdim. Burada server ve client authentication için herhangi bir işlem yoktur. Bu şablon içerisinde zaten bulunmaktadır.
Aşağıda göründüğü gibi mmc ile sertifikaları açıp yanına bir de yönetici yetkisiyle command prompt açtım. Sertifikalar içerisinde clsbroker.intra.local adında bir sertifika henüz bulunmuyor. Zaten aldığımız hatanın sebebi de bu idi.
Aşağıda göründüğü gibi sırasıyla işlemlerimizi yapıyoruz. Kullanacağımız komut certreq komutudur. Öncelikle inf dosyasından bir talep (replicacert.req) dosyası alacağız
(certreq –new cert.inf replicacert.req)
sonra bunu sertifika olarak ürettireceğiz
(certreq –adminforcemachine –submit replicacert.req replicacert.cer)
Bu aşamada request id yi not edin çünkü sıradaki komutta bu idyi kullanacağız. Eğer kaçırırsanız CA üzerindeki “issued certificates” altından kontrol edebilirsiniz.
Sonra sırasıyla
(certreq –retrieve “request idniz /bende 136” clsbroker.cer)
adıyla sertifikayı alıp,
(certreq –accept clsbroker.cer) ile sertifikalar içerisinde görebiliyor olacağız.
Artık replikasyon işlemleri için kullanabileceğimiz bir sertifikaya sahip olduk. Ve hata aldığımız kısımda işler bir sertifikamız bulunuyor.
Felaket merkezindeki sunucumuz için replikasyon ayarlarını da yaptıktan sonra broker işleme hazır olacaktır.
Bu aşamada yapılandırmamıza göre windows firewall üzerindeki ayarlamaları her node için yapmalısınız. Hatta her ne kadar sorun çıkmasa da tüm nodelar ve hedef üzerine ürettiğiniz sertifikayı private key ile export edip, import edebilirsiniz.
Hedef sunucudaki replikasyon ayarlarında da nodeları tek tek girmek yerine clsbroker CAP girmeliyiz.
Son olarak isteğinize göre hyper-v manager veya failover cluster manager üzerinden sanal sunucunun replikasyon ayarlarını yapılandırıp işlemlerimizi sonlandırıyoruz.
