Exchange 2010 üzerinde yeni High Availability çözümü olan DAG’ı http://www.anilerduran.com/index.php/2009/exchange-2010-yeni-high-availability-ozellikleri/ yazımızda incelemiÅŸtik.Organizasyonunuza DAG implemente etmek için dikkat etmeniz gereken önemli noktalara bu yazıda deÄŸinelim.
En genel gereksinimlerden baÅŸlayacak olursak
-Ortamda DNS sunucusu olmalı ve Exchange için host (A) kyıtları varolmalı
-DAG üyesi tüm exchange sunucular aynı domain üyesi olmalı
-Ãœzerinde hem exchange 2010 hemde directory servisi olan sunucular DAG member olamazlar
-DAG üyelerinin Exchang 2007′de olduÄŸu gibi makina isimleri unique ve 15 karakterden az olmalı
Donanım tarafında gereksinimlere bakarsak, DAG kullanmak için spesifik bir donanım gereksinimi bulunmuyor.Planlamanızı üzerinde çalışacak rollere ve hizmet vereceğiniz kullanıcı sayısına göre planlamanız gerekiyor.Bunun için aşağıdaki linki inceleyebilirsiniz.
http://technet.microsoft.com/en-us/library/aa996719(EXCHG.140).aspx
Yazılım tarafında DAG üyesi tüm sunucular AYNI işletim sistemini çalıştırmak zorundalar.Aynı zamanda DAG cluster servisini kullanacağı için işletim sistemlerinin Enterprise sürüm olması gerekmektedir.
Network gereksinimleri kısmına biraz bakalım.
Önceki exchange versiyonlarında da her zaman best practices olarak min iki network kartına sahip olmamız istenmişti.Private kısmı cluster servisinin kullanması için(replikasyon,log shipping), public kısmı ise internal networkümüze bakan clientların ve diğer sunucuların erişimi için dedicate ediyorduk.
Exchange 2010 ile birlikte bu isimlendirme biraz değişti.Artık public private yerine MAPI ve REPLICATION networklerimiz var.MAPI clientlara hizmet veren public taraf, replication ise adından da anlaşılacağı gibi cluster hizmetinin kullanacağı private taraftır.
Aynı zamanda Exchange 2010 ile birlikte tek network üzerinden de clusterı çalıştırabilirseniz.Yalnız bu desteklenen bir konfigurasyon olmasına rağmen önerilen her zaman minumum iki network ile çalışmaktır.
Şunuda bilmenizde fayda var.Eğer MAPI network üzerinde bir fail gerçekleşirse cluster devreye girip diğer sunucudan hizmet vermeye devam edecektir.
Eğer Replication networkü fail olursa cluster servisi replikasyon için MAPI networkünü kullanmaya başlar.Replication networkü geri geldiğinde ise tekrar buradan devam eder.
Bir diğer önemli gereksinim yapıda sunucu başına kaç network kullanmaya karar verdiyseniz tüm DAG üyelerinde bu sayı aynı olmalıdır.
Eğer coğrafi bir cluster hizmetinden bahsediyorsak tüm DAG üyelerinin aralarındaki round trip network latency değeri 250 ms altına düşmemesi gerekiyor.
Bunun dışında tabi networking tarafında dikkat etmeniz gereken REPLICATION networkü üzerinde gereksiz tüm trafiği önlemektir.Bunun için DAG üyelerinde
Client for Microsoft Networks
File and Printer Sharing for Microsoft Networks
disable etmeniz gereklidir.Aynı zamanda replication network kartları kendilerini dns’e register etmemeleri gereklidir.Bunuda gene advanced ayarlarında bulunan Register this connection’s addresses in DNS ayarı ile gerçekleÅŸtirebilirsiniz.
Exchange 2007 ile birlikte Back pressure özelliğini tanımıştık.Exchange sunucumuz belirli kaynakların yetersizliği durumunda(disk,memory vb.) gelen bağlantıları kabul etmeyip mail trafiğini durduruyordu.Hatta istersek edgetransportexeconfig dosyasını editleyerek back pressure özelliğini direk kapatabilir yada kriterleri değiştirebilirdik.
Exhange 2010 üzerinde de back pressure aynı şekilde yer alıyor.Yalnız dikkat etmeniz gereken çok çok önemli bir nokta var.Artık gelen smtp isteklerine cevap veriyor ama gelen mesajları reject ediyor.Neden buna dikkat çekiyorum?
Çünkü Exchange 2007′de bir sorun anında sunucuya baÄŸlanıp bir smtp session baÅŸlatmayı denerdik.EÄŸer baÅŸarısız olursa sebebinin back pressure olabileceÄŸini düşünebilirdik.Çünkü kaynaklar yetersizce incoming hiçbir baÄŸlantı kabul edilmiyor.
Ama aynı şeyi 2010da düşünürsek.Diyelimki sunucu back pressure durumuna geçti ve mailler gitmiyor.Bu durumda bir smtp session başlatıp sunucu isteklere cevap veriyormu diye bakarsak verdiğini görürüz.Ancak iş mail gönderimine geldiğinde ne yazıkki bu başarısız olacaktır.
Exchange 2010 ile birlikte gelen yeni özelliklerden bir taneside Shadow Redundancy.Kısaca ne olduğundan bahsedelim.
Aslında Exchange 2007′de karşımıza çıkan güzel bir özellik vardı.Transport Dumpster.Bu özellik sayesinde cluster ortamında Hub sunucusu mailleri cluster mailbox databaselere iletirken bunu belirli retention deÄŸerlerine göre transport dumpster havuzunda tutuyordu.Böylece bir fail durumunda cluster mailbox server yapıdaki tüm HUBlardan transport dumspter içeriÄŸini isteyerek kaybı önlüyordu.Yalnız bu özellik sadece CCR tarafında gerçekleÅŸiyor en önemliside iki transport server arasında (HUB-HUB / HUB-EDGE) bir geri dönüş ne yazıkki saÄŸlamıyordu.
Shadow Redundancy ise transport dumpster’ın daha kapsamlısı diyebiliriz.Shadow Redundancy enable ettiÄŸinizde neler olduÄŸunu aÅŸağıdaki figur üzerinden gidelim adım adım.
A ) Bir mapi yada mobile client mesaj gönderir ve bu mesaj mailbox server rolünü tutun sunucu üzerinde tutulur.
B ) Klasik işleyiş burda da devam eder,mail submission servisi HUB sunucusunu uyararak yeni bir mail olduğunu bildirir.HUB bu maili kullanıcının outboxundan alarak kendi databaseine yazar.
C) Burdan sonra eğer alıcı aynı site içerisindeyse mail gönderilir.
D)Eğer alıcı başka bir site üzerinde ise HUB bunu başka bir transport servera atacaktır.Burada başka bir HUB sunucuda oalbilir yada yapıdaki EDGE sunuuda olabilir.
Shadow Redundancy için önemli olan transport serverların yani hopların bu özelliği desteklemesi.Hali hazırda sadece Echange 2010 sürümü bu özelliği desteklemektedir.Yani EDGE sunucuda 2010 ise aralarında Shadow Redundancy processini başlatacaklar.Bu process şöyle işlemektedir.
- HUB sunucu EDGE’e bir smtp sessionı baÅŸlatır.
-EDGE sunucu Shadow Redundancy desteklediği bilgisini geri dönüş yapar.
-HUBÂ bunu XSHADOW komutu ile cevaplar.
-HUB mesajı EDGE’ e gönderir.EDGE bu mesajın HUB tarafından shadowlandığına dair bir iÅŸaret koyar.
-HUB da aynı ÅŸekilde EDGE’i primary server olarak görür ve shadow kuyruÄŸuna ekler.
Bu noktadan sonra HUB sunucu mesajı silmeyecektir.Ancak EDGE tarafından discard status mesajı gelirse,yani bir sonraki hopa başarılı şekilde ulaştırdım bilgisi ulaşırsa ,o zaman bu mesajı kendi databaseinden silecektir.
Burada EDGE’in mesajı nereye gönderdiÄŸi önemli deÄŸil.Shadow Redundancy desteklemeyen bir sunucuyada gönderse o sunucudan onay bilgisini alır almaz , HUB sunucusuna discard status mesajını gönderir ve mesajı artık silebileceÄŸini belirtir.
Eğer EDGE mesajı Shadow Redundancy destekleyen başka bir transport sunucuya atarsa yukarıdaki durum yanı şekilde EDGE ve bu sunucu arasındada gerçekleşir.
Dikkat ederseniz ortamdaki transport sunucularınızdan birisi down olduğunda yada siz bakım için offlinea aldığınızda üzerindeki mesajlar Shadow Redundancy sayesinde kaybolmuyor.Çünkü henüz mesajı iletmediği için bir önceki hop üzerinde zaten bu mesajlar tutuluyor.
Peki bu özelliği nasıl enable edeceğiz?
Grafiksel olarak Shadow Redundancy özelliğini yönetebileceğiniz bir arayüz yok.Bunun için shell komutlarını koşturmanız gerekli.
Set-TransportConfig -ShadowRedundancyEnabled $true
 komutu ile Shadow Redundancy enable edilrbilir.Aynı zamanda ilgimi çeken diğer bir güzel komutta shadow altında tutulan mailler için bir age sınırı belirtebilmeniz.Default gelen ayarlarda shadowda tutulan mailler 2 gün geçtikten sonra silinir.İsterseniz
Set-TransportConfig -ShadowMessageAutoDiscardInterval 04:00:00
gibi bir komutla bunu 4 saate çekebiliriz.
BildiÄŸiniz gibi SCCM 2007 ‘yi Server 2008 üzerine kurduÄŸunuzda IIS 7 üzerinde birkaç konfigurasyonu gerçekleÅŸtirmeniz gerekli.Ancak tüm bileÅŸenleri doÄŸru yapılandırdıktan sonra SCCM tarafında sıkıntısız devam edebiliyorsunuz.Gerek SCCM upgrade senaryolarında gerekse acil durumlar için SCCM site yedeÄŸini alabiliyoruz.Tabi bunun yanında o kadar konfigurasyonu gerçekleÅŸtirdiÄŸimiz IIS’in yedeÄŸinide almak faydalı olacaktır.
IIS 7′de backup ve restore iÅŸlemi oldukça kolay.Hazırlanmış olan bir scripti kullanarak aÅŸağıdaki ÅŸekilde backup/restore iÅŸlemlerini gerçekleÅŸtirebilirsiniz.
Backup almak için;
 %windir%\system32\inetsrv\appcmd.exe add backup “My Backup Name”
Backuptan dönmek için;
 %windir%\system32\inetsrv\appcmd.exe restore backup “My Backup Name”
Alınan backupı silmek için;
 %windir%\system32\inetsrv\appcmd.exe delete backup “My Backup Name”
inetsrv altında backup klasöründe alınan backup dosyalarınızı görebilirsiniz.
SP1 RTMÂ Â Â Â Â 4.00.5931.0000
SP1Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 4.00.6221.1000
SP2 RCÂ Â Â Â Â Â Â Â 4.00.6468.2001
SP2 RTMÂ Â Â Â 4.00.6487.2000
SCCM 2007′yi Server 2008 üzerinde kurmak istediÄŸinizde on hazırlık konfigurasyonları biraz daha farklı ilerliyor.Özellikle IIS üzerinde yapmanız gereken konfigurasyonları inceleyelim.
Öncelikle Server Manager ekranından IIS bileşenini ASP.NET ile birlikte kurmanız gerekmektedir.
Kurulumun ardından Webdav 2008de gelmediği için aşağıdaki linklerden uygun versiyonu indirerek kurmanız gerekmekte.
Microsoft WebDAV Extension for IIS 7.0 (x64)
Microsoft WebDAV Extension for IIS 7.0 (x86)
Kurulumu bitirdikten sonra IIS konsolu altından WEBDAV’ı enable edelim.
Authoring ayarlarını konfigur edelim
Basic Authentication ve Windows Authenticaton rol servislerini yükleriz.World Wide Web servisini yeniden başlatırız.
Windows Authentication’ı enable ederiz.
Åžimdi Default Web Site üzerinde Authorization Rules’a çift tıklayın.(EÄŸer bu ikonu göremiyorsanız IIS bilÅŸenlerinden URL Authorization’ı ekleyin)
Authhorization Rules altında All users için allow izninin olduğunu doğrulayın.
Artık administrator hesabını kullanarak webdav testini gerçekleştirebiliriz.
net use * http://localhost/
Aşağıdaki gibi network path not found hatası alıyorsanız Desktop Experience Feature yüklemeniz gerekli.
The file cannot be accessed by the system hatasını alırsanız IIS Manager altında Webdav Authoring Rules altında ilgili kullanıcıyı read,write hakkı ile ekleyin.Yada authentication bölümünde
basic authentication enable edebilirsini.Tabi bu bir güvenlik riski oluşturacağından sslli kullanmanızı öneririm.
Eğer herhangi bir hata yoksa IIS 6.0 Management Compatibility role servisinide yükleyelim.
Features altından Bits Server Extensions yükleyelim.
Aynı zamanda IIS rol servislerinden ASP yüklümü mutlaka kontrol edelim.
SCCM 2007 kurulumu için IIS üzerinde temel yapılması gerekenler bundan ibaret.Artık SCCM kurulumuna başlayabilirsiniz.
SCCM 2007 sitelarınızın yedeğini almak oldukça basit bildiğiniz gibi.Task altından Backup processi için bir schedule tanımlayıp yedeği başlatabiliriz.Yalnız burada alınan yedek neleri içeriyor çok iyi bilmeniz gerekiyor.Kısaca inceleyelim.
NELERİN YEDEĞİ ALINIR
- Configuration Manager Site Database ( SQL Server Database)
- Configuration Manager kurulum dizini
- Master Site Control dosyası (.\Inboxes\Sitectrl.box\Sitectrl.ct0)
- SMS ve NAL registry anahtarları
NELERİN YEDEĞİ ALINMAZ
Yedekleme işlemi sırasında SCCM kurulum dizinindeki logların yedeği alınır fakat diğer dizinlerde bulunan log dosyalarının yedeği alınmaz.Bunun için alternatif bir metod bulmanız gerekli.
SQL Server üzerindeki master database yedeğinin alınmasına gerek yoktur.Bu olmadanda restore işlemini yapabiliriz.
Site backup process’i sırasında CONFIGMGR clientların yedeÄŸi alınmaz.
System Center Configuration Manager 2007 R2 sürümü ile birlikte gelen yeniliklerden bir taneside SQL Server Reporting Services ile artık tümleşik çalışabilmesi.
SCCM altında raporlamaları kendi bünyesindeki report servisinden gerçekleştiriyorduk.Uzun zamandır SQL Server reporting kullananlar sccm kosnolu altında raporlarla uğraşırken bazı zorluklar yaşayabiliyordu.Artık birbirine entegra biçinde çalışan bu iki servisten en verimli şekilde faydalanabilecekler.
Bunun dışında bu noktada en beğendiğim özelliklerden biriside , Sql Reportin Servisi altında raporlar için mail tasklar oluşturabiliyorum.Yani rapor oluştuğunda smtp servisini kullanarak yöneticiye mail atabilmesini sağlayabiliyorum.Eğer SCCM de de SQL Reporting servisini kullanarak custom rapolar oluşturursanız bu tarzda bir notification belirleyebilme şansınız var.
Yalnız bu entegrasyonu kullanabilmek için birkaç ön gereksinim var.İsterseniz yapılması gerekenleri adım adım inceleyelim.
1 ) Öncelikle yapınızda kullanıdığınız SQL Server için reporting service i yüklemiş olmanız gerekiyor.Eğer ilk kurulum sırasında bu işlemi gerçekleştirmediyseniz istediğiniz zaman kurulum DVDsini takarak ilgili bileşeni kurabilirsiniz.
2) Aynı zamanda bu bileşen üzerinde birkaç ayar gerçekleştirmeniz gerekli.Bunun için
Microsoft SQL Server 2005 / Conffiguration Tools altında Reporting Services Configuration konsolu açılır.
Report Server Virtual Directory ekranında New ile Default Web Site üzerinde ReportServer isimli bir virtual directory oluşturulur.
Report Manager Virtual Directory altında New ile Default Web Site üzerinde Reports isimli bir virtual directory oluşturulur.
Database Setup bölümünde Reporting Services sunucusu seçilerek connect tıklanır.
Database Connection sayfasında Configure Report Server bölümünde New ile yeni bir database oluşturulur.
Ve email settings kısmında oluşturulan custom raporlar için email subscriptionları oluşturabilirsiniz.
Tüm bunların dışında SCCM tarafında da bu servisi kullanmak için yapmanız gereken ufak bir konfigurasyon var.
Site Database / Site Management / Site code / Site Settings / Site Systems altında inerek New ile yeni bir rol ekleme sihirbazını açarız.Bu kısımda seçmeniz gereken rol Reporting Services point dir.
Artık Report containeri altında Reportin Service isimli yeni bir container göreceksiniz.Bu kısımda sağ klik create reports ile SQL tabanlı raporları tabledan çekerek oluşturabilirsiniz.
Configuration Manager 2007 clientların WSUS üzerinden gerekli olan update listesine ulaşabilmeleri için üzerinlerindeki Windows Update Agent (WUA) versiyonunun 3.0 olması gerekiyor.Bu versiyon bilgisini görüntülemek için iki yöntem kullanabilirsiniz;
1)Software Updates Report kullanarak
Configuration Manager konsolu altında Site Database / Computer Management / Reporting /Reports dizininde Scan1- Last Scan States by collection raporu çalıştırılır.Rapor altında Windows Update Agent Version bölümünde versiyon bilgisi görüntülenebilir
2) Resource Explorer kullanılarak
Yine Configuration Manager konsolunda Site Database / Computer Management / Collections altında ilgili clientları barındıran collection için resource explorer çalıştırlır.Hardware bölümünde aynı şekilde Windows Update Agent Version bölümü incelenebilir.
BildiÄŸimiz gibi Windows Server 2008 R2 üzerine Exchange 2007′yi SPli dahil kuramıyoruz.R2 ile birlikte ancak Exchange 2010′un destekleneceÄŸi duyurulmuÅŸtu.
Yalnız müşterilerden alınan feedbackler doğrultusunda yakın zamanda çıkarılacak bir update paketi ile Server 2008 R2 üzerine Exchange 2007 desteklenir hale gelecek.İlgili msexchangeteam duyurusunu aşağıdaki adreste bulabilirsiniz.
http://msexchangeteam.com/archive/2009/11/04/453026.aspx
Varolan SCCM 2007 Primary site’ımıza yeni bir SCCM Secondar Site eklemek istediÄŸimizde bazı noktalara dikkat etmemiz gerekiyor.Bu noktaları inceleyelim.
-Secondary kurulacak sunucu üzerinde IIS’in yüklü olması opsiyonal bir gereksinimdir.Fakat bizim için önem arz eder.EÄŸer clientların Secondary site üzerindeki Management Point’e ulaÅŸmasını istiyorsanız IIS kurulumunu gerçekleÅŸtirmemiz gerekli.BildiÄŸiniz gibi SCCM management point için IIS üzerinde bir virtual directory oluÅŸturacaktır.
-Aynı zamanda IIS üzerinde bits ve Webdav enable edilmiş olmalı.
-Primary server üzerindeki local users and computers bölümünde secondar server computer hesabını Administrator ve SMS_Sitetositeconnection grubuna üye yapılır.
-Schema extend iÅŸlemi.Bu iÅŸlemi primary server’ı kurarken gerçekleÅŸtirmiÅŸ olabilirsiniz.BildiÄŸimiz gibi SCCM altında schema extend forest bazında gerçekleÅŸir.Fakat yinede secondary altında bu iÅŸlemi gerçekleÅŸtirip baÅŸarılı bir çıktısını görmek güvenli olacaktır.Schema extend için SCCM dvdsi içinde D:\SMSSETUP\BIN\I386\EXTADSCH.EXE yi kullanabilirsiniz.BaÅŸarılı olduÄŸuna dair logu C: dizini altına düşecektir.
-Msxml6 yüklü olması gereklidir.
Bu işlemlerden sonra bir öngereksinim testi yapabilirsiniz.Ardından standart kurulumu başlatarak Secondary site menusunu seçmeniz yeterli.Sizden secondary site için bir site code isteyecektir.Unique bir kod girdikten sonra bir sonraki bölümde primary site kodunu isteyecektir.Bunuda girdikten sonra dns hiyerarşinizde bir problem yok ise kurulum başarılı bir şekilde tamamlanır.Bundan sonra yönetimi tek bir konsol altından iki site içinde gerçekleştirebilirsiniz.
Kota mesajları Microsoft Exchange tarafından mailbox ve public folder kullanıcılarına otomatik olarak gönderilen ve storage kota limitlerine ulaşdıldığını belirten uyarı mesajlarıdır.Organizasyon bazında kota limitleri belirlediğimizde ilgili değerlere ulaşıldığında kullanıcılara bu uyarı mesajları gönderilir.
İstersek bu uyarı mesajlarını customize edebilme şansımız bulunuyor.Bu işlem için kullanabileceğiniz cmdlet leri:
New-SystemMessage
Get-SystemMessage
Set-SystemMessage
Remove-SystemMessage
Birkaç örnekle açıklayalım.HUB üzerindeki management shellde aşağıdaki komutu koşturabiliriz.
New-SystemMessage -QuotaMessageType WarningMailbox -Language EN -Text “This is a custom quota message.”
Warning kotasını aştığında gönderilecek uyarı.Buradaki WarningMailbox yerine ProhibitSendMailbox ve ProhibitSendReceiveMailbox parametreleri ile gönderim ve gönderim/alım kota değerlerine ulaşıldığında gönderilecek uyarı mesajlarını editleyebilirsiniz.
Custom oluşturulan kota mesajlarını görüntülemek için
Get-SystemMessage -Identity EN\WarningMailbox | Format-List
Aynı şekilde oluşturulan custom mesajları silmek için
Remove-SystemMessage -Identity EN\WarningMailbox
Exchange 2003′de purge iÅŸlemimiz vardı.Yapıdan silinen mailboxlar belirlenen gün sayısı kadar disconnected olarak kalıyor ve istenildiÄŸinde geri döndürülebiliniyordu.Purge iÅŸlemi ile disconnect olan mailboxları veritabanından tamamen silebiliyorduk.Exchange 2007′de bu iÅŸlemi powershell’i kullanarak gerçekleÅŸtirebiliriz.
Disconnected mailboxların listelenmesi
Get-MailboxStatistics | where-object { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid
Silinme iÅŸlemi
$users = Get-MailboxStatistics | where-object { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid
Failover Cluster konsolu altında CSV eklediğinizde arayüzden bunu tekrardan kaldırma şansınız yok.İçerisine bir disk eklemesenizde CSV hep orda duracaktır.Bunu sizde benim gibi kullanmadığınız zamanlar kaldırmak istiyorsanız aşağıdaki komut işinizi görecektir.
Get-Cluster | %{$_.EnableSharedVolumes = "Disabled"}
Hepimizin bildiği NTFS aslında clustered bir dosya sistemi değildir.Aynı anda sadece tek bir sunucunun erişim yapması için tasarlanmıştır birden fazla sunucu aynı anda erişim sağlayamaz.
Yalnız bir cluster yapısı düşündüğünüzde genel mantık ÅŸu ÅŸekildedir.Nodelardan birisi aktiftir ve kaynakları üzerinde tutar diske eriÅŸim saÄŸlayabilir.Cluster üzerindeki service yada application diÄŸer node üzerine taşınacaksa öncelikle fiziksel diskteki kaynak dismount edilir ve diÄŸer node’a taşınıp aktif hale getirilir.Burada birkaç saniyelik downtime’a düşme durum vardır.
Yalnız bu özellikle cluster yapısında sanal makinalar bulunuyorsa istenmeyen bir şeydir.Özellikle Live Migration gibi teknolojilerde hiçbir kayıp olmadan geçiş bizim için önemlidir.
R2 ile birlikte buna karşılık yeni bir yapı mevcut.Cluster Shared Volume (CSV) özelliği ile burada yeralan tüm disklere yapıdaki tüm nodeların erişim şansı bulunuyor.Yani diskler eskiden olduğu gibi aktif olan node altında yer almıyor tüm nodelar tarafından görünür halde karşımıza çıkıyor.
CSV yapısı %systemroot%\clusterStorage altındaki dizinde Volume1-Volume2 gibi isimlerle yer alıyor.
Böylece farklı bir node içerideki VHD’yi baÅŸlatmak istediÄŸinde belirli bir süre geçmesine gerek kalmıyor çünkü hali hazırda herkes bu volumelere eriÅŸim saÄŸlayabiliyor.
DiÄŸer yazılarda CSV konfigurasyonlarına deÄŸineceÄŸim yalnız bilmeniz gereken çok önemli bir ayrıntı var.CSV’yi aktif etmek istediÄŸinizde de size söylendiÄŸi gibi bu yapı sadece Hyper-v destekliyor.
Geçen günlerde ESX Server üzerinde vmotion ve HA videolarını yayınlamıştım.Aynı sistem üzerinde ( 2 adet HP Proliant sunucu,iscsi san) bu sefer Server 2008 R2 ile birlikte gelen en ses getiren teknolojilerden biri olan Live Migration ve Failover Cluster üzerinde HA uygulamasını gerçekleştirip gene videoya çektim.Live Migration mimarisi hakkında ayrıntılı yazıları yakın zamanda fırsat buldukça yayınlamayı düşünüyorum o zamana kadar aşağıdaki video size biraz fikir verebilir.ESX Server tarafındaki vmotion ve HA ile yapılanların aynısı hiçbir fark olmadan yapılabiliyor.Videoları aşağıdan download edebilirsiniz.
Bölüm 1 — Failover Cluster Servisinin kurulumu – iscsi konfigurasyonu
Bölüm 2 — Hyper-V Cluster Konfigurasyonları
Bölüm 3 — Live Migration ve High Availability Testleri
Windows Server 2008 R2 Failover Cluster konsolunu inceledikçe yeni özellikleri keşfetmeye devam ediyorum.Eklenen yeni özelliklerinden biriside Auto Start kutucuğu.
Cluster konsolu altında oluşturduğunuz herhangi bir grubun özelliklerine geldiğinizde Auto Start kutucuğunu görebilirsiniz.
Varsayılan oluşturulan cluster grupları için bu ayar işaretli gelecektir.Yaptığı işlem ise basit.Herhangi bir cluster servis yada application offline durumu düştüğünde tekrardan recover edilmesini otomatik gerçekleştiriyor.Yani online durumu otomatik olarak geçiş gerçekleşiyor.Özellikle Virtual Machinelerin olduğu bir cluster yapısında priority olarak düşünebilirsiniz bu ticki.Node offline durumu düştüğünde düşük öncelikle gruplardan bu işareti kaldırırsınız ve yüksek öncelikli örneğin sanal makinaların blunduğu grup otomatik olarak online duruma geçer.
Åžuna dikkat etmeniz gerekli.EÄŸer grup üzerinden bu ticki kaldırırsanız mutlaka manuel olarak bu grubu size online’a çekmeniz gerekiyor.Aksi takdirde kendisi herhangi bir aksiyon almayacaktır.
ve 240 yorum bulunmaktadir.
