2008 R2 Failover Cluster Rolünün Server 2012’ye yükseltilmesi
Uzun yıllardır aktif olarak çeşitli görevler için kullandığımız Failover Cluster özelliği Server 2012 ile birlikte çok daha gelişmiş özellikler kazandı. Haliyle yöneticiler daha iyiye geçiş yapmayı düşüneceklerdir. Failover Cluster’daki yenilikler başka bir makalenin konusu olmakla birlikte bu makalede 2012’ye geçişi inceleyeceğiz.
Örneklerimizde 2 nodelu yapı üzerinden hareket edeceğiz. Yapımızda aşağıdaki yüksek erişilebilir (HA) sunucular bulunmaktadır. Bir sunucumuzda “Generic Application” şeklinde hesap makinesi uygulamasını, birinde “file server” ile bir dosya sunucusunu, diğerinde de bir DHCP sunucuyu HA hale getirdim.
Bahsettiğim sunucuların tamamı için Client Acces Point (erişim noktaları) isimleriyle aynıdır. Detaylarına baktığımızda hesap makinesinin belirlediğimiz erişim noktasından çalışıp çalışmıyor olduğunu sorgulamak için “tasklist /s 2K8R2Calculator” komutunu kullanıyoruz.
Dosya sunucusu için server 2012’nin yeni özelliği iSCSI Target ile oluşturduğumuz bir diski her iki sunucuda da “File Server” özelliklerini aktive edip yapılandırdık. Üzerinde CPFile_Test adında bir paylaşım oluşturduk ve bu paylaşıma \\cp2008r2clsfs erişim noktasından erişebilmekteyiz.
DHCP sunucumuz da üzerinde 10.50.50.50-60/24 havuzundan IP dağıtacak şekilde ayarlanmış durumdadır.
Ortamdaki sunuculara biraz ek özellik katıp dosya sunucumuza 10.0.40.50 IP adresini ekliyor ve bu kaynağın FileDisk kaynağına bağımlı olmasını sağlıyoruz.
Aynı şekilde hesap makinesi uygulamamız için de notepad uygulamasını ek kaynak olarak atayıp, hesap makinesinin çalışmasını HA erişim noktamıza ek olarak bu uygulamaya da bağımlı kılıyoruz.
Geçiş için ön yapılandırmamızı tamamladık. Şimdi birkaç geçiş senaryosundan öncelikle uzun ve zahmetli olan metodları inceleyelim:
Failover Cluster rolü her iki işletim sisteminde de tek node üzerinde oluşturulabilmektedir. Yani oluşturulması ve devamlılığı için ek bir node’a ihtiyaç yoktur. Buradan hareketle bir sunucuyu cluster üyeliğinden düşürüp, işletim sistemini yükselttikten sonra görevleri bu sunucu üzerine alabiliriz. Ya da tüm sunucularımızın üyeliklerini keserek (evict) cluster’ı ortamdan kaldırıp (destroy), sunucularımızı Server 2012 işletim sistemine yükselttikten sonra gerekli depolama bağlantılarını yapıp eski sanal sunucularımızı yeni cluster yapımıza dahil edebiliriz.
Dikkat edeceğiniz gibi bu senaryo Hyper-V rolünün aktive edildiği ortamlarda geçerli olacaktır. Vhd ve vhdx değişimi de önerildiğinden ve System Center Virtual Machine Manager ile de yapılabildiğinden başka bir makalede bu senaryonun ayrıntılarına da gireceğiz.
Ayrıntılarını inceleyeceğimiz ve Hyper-v üzerindeki sanal sunucuların bulunmadığı ortamımızda sorunsuz geçişi sağlamak için ayrı bir yapı üzerinde Server 2012 üzerinde failover cluster yapılandırmasını yaptıktan sonra client access point (CAP) üzerine sağ tıklayıp, “More Actions” altında görebileceğimiz “Migrate Roles” seçeneğidir.
Bu senaryomuz mevcut yapıdan farklı iki sunucu ve depolama alanı gerektirmesi yüzünden biraz maliyetli görünebilir. Fakat cluster özelliğinin tek sunucu üzerinde de aktive edilebilmesi ile maliyeti düşürebiliriz. Yani bir nodeunuzu cluster üyeliğinden düşürüp, server 2012’ye yükseltip tek node’lu iki adet cluster sahibi olabilirsiniz. Gerekli düzenlemelerden sonra mevcut sunucularınızla tüm işi kotarmış olursunuz.
Migrate Roles özelliği Server 2008 SP2, 2008 R2 SP1 ve 2012 üzerinden Server 2012’ye yapılabilir.
İlk aşamada hangi cluster veya node üzerinden taşıma yapılacağı sorulmaktadır. Yapılanmamız için geçerli cluster ismi CP2008R2CLS’dir.
Ufak bir sorgulamadan sonra taşınabilir rollerinizi göreceksiniz. Detaylarını açabilir, sizin için artık geçerli olmayan veya eski cluster yapısı üzerinde kalmasını istediğiniz servisleri eleyebilirsiniz. Aşağıdaki resimde dikkatinizi çekeceği gibi bazı rol ve hizmetler ünlem ile “ek işlem gerektirebilir”(This role may require additional manual steps) bildirimini veriyor.
“View report” butonuna bastığınızda işlem öncesi ve sonrası yapmanız gereken, taşınabilecek ve taşınamayacak değerleri görebilirsiniz. Benim karşıma çıkan bildirimde hesap makinesi ve bunun içerisine ek kaynak olarak tanımladığımız notepad uygulamasının daha önceden hedef yapıya yüklenmesi gerektiğini, DHCP rolünün hedef clusterın tüm üyelerinde yüklü olması gerektiği, depolama alanlarının taşınamayacağı belirtilmiş. File Server için herhangi bir sorun çıkmamış.
Dolayısıyla öncelikle hesap makinesi ve notepad uygulamalarımın yeni clusterdaki nodular üzerinde aynı yerde olup olmadıklarını edip, yeni cluster nodelarıma DHCP rollerini ekledikten sonra işlemleri tekrar deneyebilirim. Ama ben uzun yolu tercih ediyorum ve bu işlemleri sonrada yapacağım.
Bir sonraki aşamada taşınamayacağı uyarısı verdiği depolama birimlerimle ilgili kararımı veriyorum. Burada mevcut disk yapılarını korumalarının yanında, yeni cluster yapımdaki müsait disklere de taşınmayı sağlayabilirim. Ben file server için eski disk yapısını korumasını, DHCP sunucum için yeni clusterdaki bir yere taşınmasını istiyorum.
Bu işlem için öncelikle DHCP satırına tıklayıp daha sonra “select storage (depolama alanı seç)” seçiyorum. Açılan pencerede elimdeki uygun diski atıyorum.
İşlem sonrası gösterilen özet ekranını geçtikten sonra işlem başlıyor.
İşlemin son ekranında, sonuçların yanında önemli bilgiler de yer alıyor. Genellikle kullanım kılavuzları, kredi kartı sözleşmelerinin detaylarını okumayan bir millet olduğumuz için bu aşamada direk olarak “Finish” butonuna basmak gibi bir yanlışa düşmemiz olası. Fakat ortama özel bilgilerin okunarak anlaşılması gerekiyor.
Bunlardan birincisi “What’s Next(sırada ne var)” bildirimi. Dikkatlice okursak: ortamda değişiklik yapmamız gereken şeyler sıradaki “possible issues” bildiriminde yer alacak. Buradaki eksikliklerimizi tamamladıktan sonra eski cluster yapısı içerisindeki tüm kaynaklarımızı pasiflememiz gerekecek. Bunların yanında ortak kullanımdaki csvler de dahil olmak üzere tüm depolama birimlerine (disk veya pool) erişimleri kesip pasifledikten sonra yeni cluster ortamında sunucularımızı açmalıyız.
Raporu kaçıranlar için c:\windows\cluster\reports altında mht uzantılı bir kayıt olacaktır.
Şuan taşınmış tüm görevlerimizi pasif durumda yeni cluster yapısının içerisinde görebilmekteyiz. Ama öncelikle DHCP özelliği için yeni sunucularımıza bu özelliği yüklemeliyiz. Daha sonra eski clusterdaki DHCP özelliğini offline duruma getiriyorum.
Yeni sunucuda rolü başlatıyorum. Rol sorunsuz başlamasına ve erişim noktası ismi doğru olmasına rağmen detaylarına baktığımda ayarların boş olduğunu görüyorum, olması gereken IP havuzu görünmüyor. Eğer DHCP rolünü işlemlerim öncesi yedeğini alsaydım en azından yapımı geri döndürebilirdim. Daha önceki aşamada DHCP için yeni cluster içinde bir depolama alanı belirlediğimden buradaki backup sizi şaşırtmamalı. Sistemde herhangi bir değişiklik yapmadan aşağıda anlatılan adımlarla DHCP klasörünü kopyalamalısınız.
Servis hala kullanımda olduğunda dhcp.mdb verisini kopyalayamayacaksınız. Bunun için eski sunucunuzu açın, DHCP rolünü devre dışı bırakın. Bu servis tarafından kullanılan disk hala erişilebilir durumda olmalıdır. Örneğimizde bu disk E:\ diskidir. Bu disk içerisindeki dhcp klasörünün tamamını kopyalayın ve kaynağı pasifleyin.
Daha sonra yeni cluster yapımızda bu işlemin aynısını yapıp, kopyasını aldığımız DHCP klasörünü tamamen yeni yerine kopyalıyoruz.
Sonra servisi olması gereken hale getirip DHCP yönetimini açtığımızda sorunun ortadan kalktığını görüyoruz. Bu işlemin bu şekilde olacağı zaten “possible issues” başlığı altında bildirilmişti. Okuduklarımızı hatırlarsak yalnızca checkpoint (erişim noktası) ayarlarının taşınacağı, depolama alanı için ya değişiklik yapmayı ya da elle kopyalamamız gerekiyordu.
Hesap makinesi uygulamamızı da aynı şekilde eski sunucuda kapatıp yeni sunucuda açıyoruz. Herhangi bir sorun yok ve ek kaynak olarak belirlediğimiz notepad ile bağımlılık ayarları da daha önce yapılandırdığımız gibi taşınmışlar. Bu işlem için “olası sorunlar (possible issues)” başlığında yalnızca uygulamaların yeni cluster içerisinde de aynı tanımla bulunması gerektiği belirtilmişti.
Gelelim dosya sunucusu rolüne. Eski sunucumuzda kapattık, fakat bunun için yeni sunucumuzda herhangi bir disk atamadan eski sunucudaki diski kullanmayı seçmiştik. Dolayısıyla eski sunucudaki bağlantımızı kesip, bu depolama birimine yeni sunucudan erişim ayarlamamız gerekiyor.
Eski sunucu bağlantımı server 2012 üzerinden iSCSI target oluşturarak yapmıştım. Ve erişim noktaları olarak eski cluster sunucularımı belirlemiştim. iSCSI target üzerindeki diskimi “assign (ata)” komutu ile eski sunucuların erişimlerini yenileriyle değiştiriyorum. Değiştirdikten sonra herhangi bir ek işleme gerek kalmıyor. Disk yönetiminde offline olarak görünüyor. Yeni cluster yapımda “file disk” kaynağımı online hale getirdiğimde herşey otomatik olarak çalışıyor. Zaten “possible issues” uyarılarını detaylı okursak yeni cluster yapımızdaki “available storage” içerisinde aynı harfli bir disk olmasına rağmen işlemlerin sorunsuz olması için bu silinmişti. Eski sunucudan aktardığımız disk bu harfi alacaktı.
Eklediğimiz IP adresi kaynağı da yeni yerinde bulunuyor ve dosya erişim noktamız içeriğiyle beraber aynı şekilde ulaşılabilir durumdadır.
Önemli sonuçlar:
1. Özellikle yüksek erişilebilirliği canlı ortamlarda yapmadan önce lab ortamında denemelerinizi yapın
2. Çıkan uyarı ve bildirimleri detaylı okumaya ve anlamaya çalışın. Aksi takdirde yukarıdaki gibi sorunlarla karşılaşabilir, bazı durumlarda işin içinden çıkamayabilirsiniz. Kısacası “kervan yolda düzülür” lafı burada işlemeyebilir
3. Özellikle eski yapınızdaki depolama alanlarını yeni cluster yapınız içerisindeki farklı disklerle değiştirecekseniz, harflerin değiştiğinde oluşabilecek sorunları öngörün ve migration işlemi öncesi çözüm bulmaya çalışın. (bkz. File server taşınması sırasında silinen eski disk harfi)
İyi çalışmalar
