Disaster Recovery & Databases

Disaster recovery (Felaket Kurtarma) hangi firmada, hangi ürünle, hangi birimde çalıştığımız farketmeksizin karşımıza çıkacak bir iş başlığı olacaktır. Teknoloji dünyasında insanların hizmet aldığı sistemlerden beklentisi 7/24 performanslı şekilde çalışmasının yanında, en ihtiyaç duyulan anlarda da hizmet vermeye devam etmesidir. Geçtiğimiz ay yaşadığımız asrın felaketi sonucunda bu durum daha iyi anlaşıldı. Olası felaket senaryolarına hazırlıklı olmak artık teknoloji şirketleri için daha önemli bir başlık haline geldi. Bu bağlamda dilim döndüğünce şimdiye kadar çalışma fırsatı bulduğum DB ürünleri için DR çözümlerinden bahsedeceğim.

Oracle Database

Veritabanı DR çözümü açısından belki de en gelişmiş ürünü sunan firmadır. Oracle, Data Guard sayesinde farklı veri merkezleri arasında oracle veritabanlarının replikasyonunu kolaylıkla sağlamaktadır. Data guard, production veritabanından redolog’ların FKM’de kurulan veritabanına aktarılması mantığı ile çalışmaktadır. Oracle’ın bir diğer ürünü olan RAC ise veritabanının cluster mimarisinde hizmet vermesini sağlamaktadır. Akıllara RAC mimarisi uygulanırken cluster node’larından bir tanesinin farklı Datacenter’da konumlandırılması ile DR çözümü olarak da uygulanabilir mi sorusu geldi ise; bu mimarinin geliştirilme amacı ve donanım seviyesinde gecikmeler vs göz önüne alındığında pek kabul gören bir yaklaşım değildir (Oracle RAC extended distance farklı bir yaklaşım sunar – Detay : https://www.oracle.com/docs/tech/database/extendedracversion11.pdf ). Scalable ve high-available bir oracle veritabanı mimarisi için RAC + Dataguard kurulumu ile devam edilmesi en optimum çözümdür.

Postgresql Database

Postgresql veritabanı da en popüler RDBMS’lerden bir tanesidir. Ürün open source olduğundan replication amaçlı 3rd party ürünler bulunsa da bunlara ihtiyac duymadan aktif – pasif bir replication mimarisi ile disaster çözümü sağlanabilmektedir. Replication WAL kayıtlarının primary’den secondary database’e gönderilmesi mantığı ile çalışmaktadır. Ayrıntılı bilgi için https://www.postgresql.org/docs/current/protocol-replication.html dökümanı incelenebilir. Ayrıca Postgresql veri tabanını cluster mimarisinde çalıştırabilmek için de patroni gibi ürünler kullanılabilir. Patroni kurulumu ve mimarisi ile ilgili detaylı yazıya burdan ulaşabilirsiniz.

Mongo Database

Mongo document based bir nosql veritabanıdır ve nosql dünyasının en popüler veritabanıdır. Datayı JSON/BSON formatında tutar ve büyük ölçekli veride yüksek performans sunar. Mongo veritabanı da replicaset’ler aracılığı ile verinin yedeklenmesini sağlamaktadır. Mongo veritabanı kullanırken replicaset cluster mimarisi ile 1 primary + n secondary sunucu konumlandırılabilir. Secondary’ler read only olarak hizmet verecek şekilde konfigürasyon yapılabilir. Primary node ile ilgili bir kesinti olduğunda clusterde bulunan secondary sunuculardan bir tanesi yeni primary olarak set edilebilir. Bu mimari aşağıdaki gibi gösterilebilir.

Replicaset mimarisinde secondary veritabanları farklı data centerlarda konumlandırılarak bir DR çözümü uygulanabilir.

Yine sharded cluster mimarisinde de mongodb cluster’da datanın hem shardlar aracılığı ile clusterda yer alan node’lar üzerinde dağıtılması hem de replicaset ile data’nın replikasyonu sağlanabilir. Bu yapıda yine her shard için replicaset’lerin node’ları Disaster DC’de konumlandırılabilir. Burda dikkat edilmesi gereken nokta production DC hizmet veremez duruma geldiğinde Disaster DC’de yer alan node’ların voting mekanizmasının doğru kurulması ile primary seçiminde hata durumundan kaçınabilmektir. https://www.mongodb.com/docs/manual/tutorial/deploy-geographically-distributed-replica-set/

Elasticsearch

Elasticsearch için database ifadesini kullanmak doğru olmasa da günün sonunda data tutan bir uygulamadır. Bu sebeple replikasyon ve disaster recovery ilkeleri elasticsearch için de uygulanmalıdır. Elasticsearch cluster yapısında hizmet verir. Shard seviyesinde data replikasyonunu sağlar. Her bir index create edildiğinde o indexe ait shardların kaç kopyasının saklanacağı bilgisi verilir. Ve clusterda primary shard datasına ulaşılamadığı zaman hemen replica shardlardan bir tanesi primary rolüne geçer. Elasticsearch’de node seviyesinde bir primary secondary ayrımı yoktur.

Elasticsearch’ün farklı datacenterlardan hizmet verebilmesi için aynı cluster’ın farklı node’ları Disaster DC’de konumlandırılarak bu node’ların üzerine sadece replica shardların tutulması sağlanabilir. Bu yöntem master node kaybı ve gecikmeler göz önüne alındığında uygulaması ve yönetmesi daha çok efor isteyen bir yöntem gibi duruyor.

Elasticsearch’ün lisansa tabi CCR – Cross Cluster replication özelliği ise farklı clusterların farklı DC’ler arasında replikayonunu sağlar. Leader ve follover index mantığı ile çalışan bu yapıda birbirinden farklı mimariler bulunmaktadır. Tek yönlü replication işlemi yapılabilir ve Disaster DC read only olarak da kullanılabilir. Bunun yanında bi-directional yani çift yönlü replikasyon da tanımlanıp iki cluster’ın da read write’a açık olması sağlanabilir. Ancak çift yönlü CCR için indexlerin Append only olması yani update alan indexler olmaması gerekmektedir. CCR index seviyesinde replikasyon yapar, indexlerden bazılarını disaster’a replike edip bazılarının taşınmaması sağlanabilir.

Cloudera – Hadoop

Cloudera ile bir big data cluster’ın yönetimi daha kolay sağlanabilir demiştik çünkü cloudera bir çoğu open source olan ve big data ekosisteminde yer alan yazılımları bir çatı altında toplar. Bu ürünlere kazandırdığı ek özelliklerle de çoğu ihtiyacı karşılar.

Data replication işi için de BDR – big data replication sayesinde hdfs – hive datasının farklı bir cluster’a replike edilmesi sağlanır. Disaster DC’ye kurulan bir big data cluster’a BDR ile istenilen verilerin replica edilmesi sağlanabilir.

Sonuç olarak sakladığımız verilerin her zaman uygulama seviyesinde farklı bir DC’ye replication’ı bir felaket durumu olmasa dahil daha küçük çaplı hatalar için bile bizim yararımıza olacaktır. İyi Çalışmalar