Microsoft Exchange Server Business Continuity Plan Tarihi içinde Exchange Server High Availability ve Exchange Server Site Resilience kavramlarını inceleyeceğiz ve Exchange Server 2010 ‘a kadar karmaşık süreçlerin nasıl kolaylaştığına tanıklık edeceğiz.
Microsoft Exchange Server 2010 ile birlikte Database Availability Group çözümleri hayatımıza girdi ve bu karmaşık başlıklar ve anlaşılması kadar uygulanması da zor olan süreçler artık son buldu.
Microsoft Exchange Server 2007 sürümünde bir çok Microsoft Exchange Server Business Continuity Plan çözümleri kötü tasarlandı, Exchange Server Disaster Recovery çözümleri de eksik yapıldı. Bu kötü sonuçlar, ihtiyaç durumunda beklentileri karşılamadı.
Microsoft Exchange Server 2016 ‘a kadar Microsoft Exchange Business Continuity Plan süreçleri karmaşık ve zordu. Exchange Server 2016 ‘a kadar yani bu gün de kullanmış olduğumuz Microsoft Exchange Server Business Continuity Plan çözümleri son halini alana kadar bir çok değişime uğradı ve artık çok daha kolay bir çözüme kavuştu.
Exchange Server 2016 ve Database Availability Group çözümlerinin esnekliği bir çok kuruluşun Microsoft Exchange Server Business Continuity Plan çözümlerini daha kolay yapmalarını, Exchange Server High Availability ve Exchange Server Disaster Recovery çözümünde ihtiyaçları kolay bir şekilde karşılamalarını sağladı.
Son yıllarda gelişen teknoloji ile birlikte yeni gereksinimler de ortaya çıktı. Microsoft Exchange Server her yerden erişim, her zaman erişim ilkesiyle birlikte cep telefonlarından, bağımsız bilgisayarlardan her an erişilen bir platform halini aldı. Bu değişim de e-posta sistemlerini ve özellikle Microsoft Exchange Server Organizasyonlarının bir çok kuruluş için iş kritik sunucular olmasına zemin hazırladı.
Microsoft Exchange Server Business Continuity Plan Tarihi çalışmamız bu makale ve video içeriğinden sonra Microsoft Exchange Server Disaster Recovery Plan Tarihi, Exchange Server Site Resilience mimarisi ve Exchange Server Database Availability Group makale ve video içerikleri ile devam edecektir.
Microsoft Exchange Server Business Continuity Plan Tarihi makalesi içinde aşağıda ki başlıkları inceleyeceğiz.
1.Microsoft Exchange Business Continuity Plan Problemleri
E-posta Sunucuları eski zamanlardan beri iş kritik sunucular olmuştur. Bu sadece Microsoft Exchange Server için geçerli değil e-posta hizmeti veren her e-posta sistemi için aynıdır.
Microsoft Exchange Business Continuity Plan çözümleri arasında yer alan Exchange Server High Availability ihtiyacı bir çok kuruluş için zorunlu ve bir o kadar da maliyetli çözümlerdir. Bütçeleri bulunan ve Exchange Server High Availability çözümlerini hayata geçirmek isteyen kuruluşların bir çok sıkıntılı süreci de bulunmaktadır.
Bu projeler, özel uzmanlık isteyen, donanım ve yazılım seviyesinde bir çok ürüne bağımlı çalışan çözümlerdi.
Eskiden, Microsoft Exchange Server günümüzde kullanmış olduğumuz Exchange Server mimarisi kadar esnek değildi ve Exchange Server High Availability projeleri de kolay ve hızlı bir şekilde uygulanamıyordu.
Exchange Server Shared Disk and Shared Nothing Disk
Exchange Server 2003 mimarisi sadece paylaşımlı bir disk alanı ve aynı özelliklere sahip en az iki sunucunun olması durumunda gerçekleşiyordu. Bu gün, Exchange Server 2016 ‘ daki gibi Database Availability Group çözümleri gibi farklı yazılım ve farklı donanım üzerine kurulması neredeyse imkansızdı.
Bir çok kuruluş Microsoft Exchange Business Continuity Plan çözümleri arasında yer alan Exchange Server High Availability ihtiyaçlarını karşılayamıyor ve zorunlu olarak single point of olarak adlandırılan tek düğüm tasarımlarıy yapılıyordu.
Microsoft Exchange Server High Availability çözümleri sadece yedekleme çözümlerinden oluşmakta ve Exchange Server Native Protection olarak bilinen yedekleme çözümleri ile sistemler tekrar çalışır duruma getiriliyordu.
Microsoft Exchange Server Site Resilience çözümleri ise başlı başına ayrı bir uzmanlık istemekteydi.
Exchange Server 2007 öncesi Felaket Konumlandırma projeleri sadece uygulama yani Microsoft Exchange Server Organizasyon seviyesinde yapılamıyordu.
Farklı coğrafi bölgeler içinde bulunan veri merkezlerine donanım seviyesinde eşitleme çözümleri yapılmaktaydı. Exchange Server Site Resilience çözümleri organizasyon yöneticilerinden ziyade donanım katmanında görev alan yöneticilerin çözümleri oluyordu.
Exchange organizasyonunu yöneten uzmanlar D:\Setup\I386\SETUP.EXE /disasterRecovery parametresine bağımlı olmaktan başka çözümleri yoktu.
2.Exchange Server Mimari Dönüşümü
Microsoft Exchange Server 2010 ile birlikte Database Availability Group çözümleri bir çok evriminden geçti ve sonrasında Exchange Server 2016 ile birlikte son şeklini aldı. Exchange Server sistemlerine uyguladığımız her bir Exchange Server Cumulative Updates ile iyileşmekte ve bir çok değişime uğramakta ve gelişimine devam etmektedir.
Exchange Server 2003 mimarisi, Frontend ve Backend olmak üzere iki farklı rolü bulunmaktaydı. Exchange Server 2007 ve Exchange Server 2010 sürümlerinde bir çok dönüşüme uğradı. Exchange Server 2013 ile birlikte Exchange Server Mailbox ve Client Acces Rol olarak özüne geri dönüş yaptı. Exchange Server 2016 ile bilikte Exchange Server Role konsolidasyon süreci son evrimini gerçekleştirdi ve tek bir rol çatısı altında Exchange Servisleri hizmet etmeye başladı.
Bu dönüşümler bizleri yormuş olsa bile her bir mimari zamanının sahip olduğu donanım ve teknoloji ihtiyaçlarına bağlı olarak evrim geçirmiştir. Hatırlayalım ve bu gün yapmış olduğumuz Microsoft Exchange Server Business Continuity Plan çözümlerine teşekkür edelim.
2.1 Exchange Server 2003 Frontend
Exchange Server 2003 Frontend olarak adlandırdığımız rol, son kullanıcılarımızın posta kutularına erişmek için tasarlanmış roldü. Exchange Server 2007, Exchange Server 2010 ve Exchange Server 2013 e-posta sistemlerinde bulunan rol eski zamanda Frontend olarak adlandırılıyordu. Şimdi ise Exchange Server 2016 ile birlikte Client Access Services olarak adlandırıyoruz..
2.2 Exchange Server 2003 Backend
Exchange Server 2003 Backend olarak adlandırdığımız rol ise son kullanıcılarımızın posta kutularını barındıran ve aynı zamanda SMTP hizmetini sağlayan Exchange Rolü idi. Exchange Server 2007 ve Exchange Server 2010 sistemlerinde Mailbox Role ve Hub Transpor Role olarak ikiye ayrıldı.
Exchange Server 2013′ de ise Hub Transport Services Role ile Mailbox Role birleştirildi. Bu dönüşüm Exchange Server 2016 da Hub Transport Services olarak son şeklini aldı ve bu gün Exchange Server 2016 sistemlerini tek bir rol olarak kullanmaktayız.
Exchange Server sistemlerinde gerçekleşen mimari değişim ve son sürüm olan Microsoft Exchange Server 2016 mimarisinin bizlere sağlamış olduğu Exchange Server kurulum ve dağıtım esnekliği projeleri kolaylaştırdı. Bakım ve problem zamanlarının da daha hızlı zaman içinde tamamlanmasını sağladı.
3.Exchange Server 2007 Single Copy Clusters
Microsoft Exchange Business Continuity Plan çözümleri bir çok dönüşüme uğradı, Microsoft Exchange Server High Availability gereksinimleri için Exchange Server 2007 üzerinde bir çok model geliştirildi. Exchange 2003 Failover Cluster yapısına göre biraz daha iyi ama aynı temel mantıkta çalışan Single Copy Clusters modeli ile Microsoft Exchange Server 2007 ‘de tanıştık.
Exchange 2007 Single Copy Clusters
Bu çözüm, Exchange Server 2003’de olduğu gibi paylaştırılmış bir disk alanı istemekte ve Exchange Server 2003’de olduğu gibi Active-Passive mantığı ile hizmet etmekteydi. Single Copy Clusters teknolojisinin sınırlamaları Exchange Server 2003’den mirastı.
O zamanlar paylaşılmış disk olarak bilinen storage çözümleri masraflı ve her kuruluş bu ürünlere sahip değildi. Bilinen bir gerçek var ki Single Copy Clusters çözümü, Exchange Server 2003 müşterilerinin donanım yatırımlarını korumaları için tasarlanmış çözümlerdi. Donanım üzerinde bir değişiklik yapmadan mevcut sistemler Exchange Server 2007 ‘e yükseltiliyorduk. Bu çözüm Exchange Server Site Resilience çözümleri için tasarlanmamış ve donanım seviyesinde uzmanlık devam etmekteydi.
Paylaştırılmış disk haricinde bir diğer masraf ise fiziksel sunucu gereksinimiydi. Passive Node olarak kullanılacak olan Exchange Server Active Node ile benzer kaynaklara ihtiyaç duyuyordu.
Ek olarak Windows Server Lisansı ve Exchange Server lisansı takip ediyordu. Masraflı çözümler ve her kuruluş için ihtiyaç olsa bile karşılanması çok gerçekçi değildi.
Ayrıca, Microsoft, Passive Node içinde ek bir lisans ücreti istemekteydi. Bu gün Passive Nod ve Exchange Server Site Resilience çözümleri için ek lisans bedeli istememektedir.
4.Exchange Server 2007 Local Continuous Replication
Exchange Server sistemleri, Exchange Server 2007 ile birlikte kritik öneme sahip sunucu sistemleri olmuştu. Exchange Server High Availability Çözümlerinin maliyetleri ise bilgi departmanlarına maliyetli çözümler olmaya devam etmekteydi.
Microsoft Exchange Business Continuity Plan çözümleri Exchange Server 2007 ile birlike bir başka, yeni bir Exchange Server High Availability çözümüne daha kavuştu. Bu çözüm Single Copy Clusters modelinden farklı ve gelecekte gelecek olan DAGs mimarisinin de alt yapısıydı. Aslında DAGs mimarisine uzaktan yakından hiç benzemese bile DAGs mimarisi bu çözümden ilham alınarak geliştirildi.
Microsoft Exchange server üzerinde tasarlanan Local Continuous Replication çözümü Exchange Server için önerilen Exchange Native Protection çözümüne bağımlılığı azaltmak için tasarlanmıştı.
Exchange Server 2007 Local Continuous Replication
Local Continuous Replication, Exchange Server sunucuları üzerinde bulunan disklerde oluşabilecek donanım tabanlı problemler için tasarlanmıştı. Bu çözüm Single Copy Cluster çözümünde ki paylaştırılmış disk gereksinimini ortadan kaldırdı.
Bu çözümde Exchange Server 2007 üzerinde tanımlanan iki farklı disk üzerinde Exchange Server Database ‘lerinin eşitlenmesi çözümüydü. Aktive Copy sürekli olarak aynı sunucu üzerinde bulunan başka bir diske verileri eşitliyordu. Bir yedekleme çözümü gibi gözükmekte ama değildi. Paylaştırılmış disk gereksinimini ortadan kaldıran çözümdü. Fakat bu çözümde Single point of hatası sunucu seviyesinde devam etmekteydi.
Basitti ama bir çok kuruluş tarafından tercih edilmedi ve daha önceki sürümlerinde görülmediği gibi gelecek olan yeni Exchange Server sürümlerinde de bulunmayan bir çözüm oldu. Tahminim, tasarlayan mühendisin de son tasarımı oldu :)
