Felaket Kurtarma’nın Yeni Reçetesi: Proxmox VE + Ceph Storage + TTEN Core

TTEN olarak, süreçleri baştan sona otomatize edilmiş Felaket Kurtarma (Disaster Recovery) hizmetleri sunmaktayız.
Bu yazımızda Felaket Kurtarma hizmetleri için kullandığımız çözüm ve teknolojilerinden, TTEN otomasyon ve entegrasyonlarından bahsedeceğiz.

TTEN, hizmet sağlamakta olduğu tüm veri merkezi noktalarında storage katmanını yüksek performans, esneklik ve ölçeklenebilirlik sunan, özgür ve açık kaynaklı bir storage çözümü olan Ceph ile sağlamakta.

Ceph, hem blok hem de nesne depolama desteği ile veri bütünlüğünü ve güvenliğini sağlarken, otomatik replikasyon ve hata tolerans mekanizmaları sayesinde kesintisiz hizmet sunmayı amaçlar.

Öncelikle “Felaket Kurtarma” ile ilgili temel iki kavramdan bahsetmeliyiz. Bu temel iki kavram Felaket Kurtarma işleminin başarı kıstasını da belirler. Bu kavramlar: RPO (Recovery Point Objective) ve RTO (Recovery Time Objective)

RPO (Recovery Point Objective) nedir?

RPO, felaket ilan edilen an ile farklı bir lokasyonda operasyonel olarak devreye alınacak sistemlerin kullanacağı verinin en son hangi noktaya (backup veya replikasyon anına) kadar güncel kalması gerektiğini tanımlar. Bir başka deyişle, bu hedef “ne kadar veri kaybının tolere edilebileceğini” ifade eder. Örneğin, RPO değeriniz 1 saat ise, olası bir felaket anında son 1 saat içerisinde edinilmiş veriyi kaybetmeyi göze aldığınız anlamına gelir.

*Burada fail-over kararını neden olan durumun veri kaybına neden olması her zaman beklenemez. Örneğin birincil veri merkezinin topyekün yaşadığı ve internet veya enerji kesintisinde veri kaybı beklenmeyeceği için fail-over sonrası sağlıklı çalışan birincil veri merkezindeki veriler doğru bir planlama ile ikinci veri merkezindeki veriler ile birleştirilebilecektir.

RTO (Recovery Time Objective) nedir?

RTO ise, felaket sonrasında sistemlerin tekrar erişilebilir ve tam olarak çalışır hale gelmesi için gereken maksimum süreyi ifade eder. Yani “operasyonların kaç dakika veya saat içinde kaldığı yerden devam edebileceği ” sorusunun cevabını verir. Eğer RTO değeriniz 2 saat olarak tanımlanmışsa, tüm kritik servislerin en geç 2 saat içinde ayağa kaldırılmasını hedeflersiniz.

TTEN’de hem RPO hem de RTO değerleri maksimum 5 dakikadır. Peki bu nasıl mümkün olabilir?

Sağlamakta olduğumuz Felaket Kurtarma hizmetinin temelinde Ceph’in RBD Mirroring servisi bulunuyor.
RBD Mirroring servisinin kabiliyetleri vasıtasıyla, Felaket Kurtarma hizmeti aktif olan müşterilerimizin hizmetleri altında yer alan Firewall ve sanal sunuculara ait sanal diskler her 5 dakikada bir farklı bir veri merkezi noktasına düzenli olarak aktarılmasını sağlıyoruz.

RBD Mirroring servisini nasıl kullandığımızı “Veri Merkezimizi Yalnızca 8 Günde ve (Neredeyse) Sıfır Kesintiyle Nasıl Taşıdık?” yazımızda da aktarmıştık.

Bu yazımızda da TTEN Core Panel ekranlarını da paylaşarak hizmet hakkında daha detaylı bilgiler vermeye çalışacağız.

*5 Dakika maksimum süredir. Felaket anına göre bu sürenin minumum 1 saniyeye kadar düşme olasılığı ile maksimum 5 dakikaya denk gelme olasılığı aynıdır.

Örnek bir VDC (Virtual Datacenter - Sanal Veri Merkezi) ürününe ait ekran paylaşarak başlayalım.
TR - IST5 kodlu veri merkezimizde yer alan “ISTANBUL” isimli VDC ürünün altında yer alan sanal sunucular:

(Ekran görüntüsü https://core.tten.net [IST5] adresinden alınmıştır.)

Bu VDC ürününde 5 adet sanal sunucu bulunuyor. LB, DB, WEB01 ve WEB02 sunucuları için DR (Disaster Recovery - Felaket Kurtarma) özelliği aktif edelim.

TTEN, ilgili sanal sunucuların DR Ready durumda olması için aşağıdaki ekranları kullanıyor:

DR özelliği aktif edildiğinde, TTEN otomasyonlarının arka planda yapmakta olduğu işlemler sırasıyla:

1. Seçili sanal sunucular ve VDC ürününe ait Firewall ile ilgili konfigürasyonlarının Disaster Recovery hizmetinin aktif edileceği veri merkezindeki sanallaştırma sistemine aktarılması.
(Sanal sunucu kaynakları birebir yapılandırılabileceği gibi, CPU ve Memory için farklı değerlerin belirlenmesi, felaket anında kullanılacak kaynakların daha yüksek ya da düşük değerler ile tanımlanması mümkün olabiliyor.)

2. İlgili sanal sunuculara ait sanal disklerin RBD Mirroring iş listesine eklenmesi ve replication görevlerinin takip edilmesi.

3. Disaster Recovery için hedef veri merkezinde çalışmakta olan TTEN Core Panel için gerekli yetkilerinin tanımlanması.

Bu adımların ve ilk data replication’ının tamamlanmasının ardından, IST5 ve ANK1 noktalarındaki TTEN Core Panel adreslerinden bakış:

(Ekran görüntüsü https://core.tten.net [IST5] adresinden alınmıştır.)

(Ekran görüntüsü https://ank1-core.tten.net/ [ANK1] adresinden alınmıştır.)

Artık ilgili hizmetin kullanıcısı, Felaket Kurtarma hizmetini herhangi bir insan iletişimi olmaksızın devreye alabilir durumdadır.
Felaket anı itibariyle ANK1 noktasındaki TTEN Core’a erişim sağlayarak Disaster Recovery işlemlerini başlatabilir.

Bunun için “DR BAŞLAT” butonu ile sürecin başlatılması yeterli:

(Ekran görüntüleri https://ank1-core.tten.net/ [ANK1] adresinden alınmıştır.)

Onay verilmesinin ardından TTEN otomasyonlarının arka planda yapmakta olduğu işlemler sırasıyla:

1. IST5 lokasyonundaki tüm sanal sunucuların Power-Off durumuna getirilmesi.*
2. RBD Mirroring işlerinin durdurulması.*
3. ANK1 lokasyonundaki sanal sunuculara ait disklerin “primary” olarak “promote” edilmesi.
4. Aktarımı gerçekleştirilen VDC ürününe ait Firewall’a, ANK1 lokasyonunda kullanabileceği WAN IP adresinin atamasının gerçekleştirilerek yapılandırmalarının güncellenmesi.
5. VPN profillerinde yer alan FQDN’e ait A Record’ların güncellenmesi.
6. Sanal sunucuların Power-On durumuna getirilmesi.

İşlemler sanal sunucu sayısına bağlı olmak üzere ortalama 2-3 dakika içerisinde tamamlanır.
Felaket anının ilanı ve Disaster Recover servisinin aktivasyonunun ardından:

(Ekran görüntüleri https://ank1-core.tten.net/ [ANK1] adresinden alınmıştır.)

Artık Disaster Recovery işlemi başarıyla tamamlanmış durumdadır.

Örnek Felaket anı ilanı ve sonrasında, DR kapsamına dahil edilen sanal sunucuların ve VDC hizmeti için yapılandırılmış olan Firewall’un ANK1 servis noktasında çalışır duruma gelmesi, insan müdahalesi olmadan gerçekleştirildi.

Bizce dikkate değer hususlar:

1. İç ağ ile ilgili herhangi bir değişiklik yapılmadı!
Tüm sanal sunucular IST5 lokasyonunda hangi IP adresleri ile çalışıyorlar ise, ANK1 lokasyonunda da aynı şekilde çalışmaya devam ediyor.

2. Firewall’da bulunan WAN IP adresi ANK1 havuzunda yer alan IP adresi ile otomatik olarak güncellendi!
Projelerinizin yayınlarına devam edebilmesi için IST5 lokasyonundaki IP adresini işaret eden A Record’ları, ANK1 lokasyonundaki IP adresi ile güncellemek yeterli.
Eğer DNS Zone’larınız CloudFlare’de bulunuyor ise “TTEN Core Entegrasyonlar” alanından API Key’inizin tanımlanması durumunda, A Record’ların güncellenmesi işlemlerini de otomatik olarak TTEN Core gerçekleştirecek!

3. VPN Kullanıcıları, Firewall NAT Kuralları, hatta Site-to-Site bağlantı yapılandırmaları, IST5 noktasında nasıl çalışıyor ise, aynı şekilde ANK1 noktasına olduğu gibi aktarıldı.
(Site-to-Site IPSec tunnel’ler için FQDN tercih edilmedi ve direkt olarak IP adresi yazıldı ise karşı uçta yer alan sistemlerde IP adresinin güncellenmesi unutulmamalı.)

4. Felaket, yalnızca kullanmakta olduğunuz hizmette değil, TTEN ve servislerinde de yaşanabilir.
Tüm kurgumuz, ana servis noktamız olan IST5 lokasyonunun tümüyle erişilmez olacağı ihtimalleri de içeriyor. Bu sebepten core.tten.net dışında, ank1-core.tten.net adresli bir TTEN Core daha mevcut.

*Felaket anında, Disaster Recovery senaryolarının işletilebilmesi ve işlemlerin tamamlanması için IST5 lokasyonuna ihtiyacımız yok!
Ancak felaket, TTEN sistemlerini etkileyen ölçekte değil ise IST5 lokasyonundaki Firewall ve sanal sunucuları kapatarak RBD Mirroring işlemlerini durdurmayı ihmal etmiyoruz.