Consul Architecture
Consul is a complex system that has many different moving parts.
Consul Architecture | Consul by HashiCorp
Consul, resmi sitesinde birçok hareketli parçaya sahip complex bir yapı olarak tanıtıyor kendini. Consul’ü bu kadar karmaşıklaştıran şey nedir hadi inceleyelim.
Consul Nedir?
Consul, kapsamlı bir Service Discovery tool’udur. Mimari açıdan bakacak olursak Paxos altyapısına sahip Raft Consensus algoritmasıdır. Consensus hakkında buradaki yazıyı inceleyebilirsiniz. Consensus konularına çok derin girmeden Consul ile alakalı olan bazı noktaları anlatmak istiyorum.
Paxos
Paxos, Distributed System Architecture yapılarında sıkça karşılaştığımız bir protokoldür. Birçok Consensus kendine özgü özelliklere ve kullanım alanlarına sahiptir. Paxos da Consensus Algorithm olması için belli başlı özelliklere sahip olması gerekiyor.
- Ağ üzerinde tek değer önerisi olsa bile seçilir ve tanınır.
- Ağ bir değer seçmeden asla node’lara değer iletmez.
- Seçilen değer daha sonra değiştirilemez.
Consensus Algorithm’in 3 temel yapısı bulunmaktadır.
Proposers(Teklif Sahibi), Acceptors(Kabul Eden), Listener(Dinleyici). Her node bu üç yapı gibi davranabilme özelliğine sahiptir. Proposers değer gönderdiğinde Acceptors bu değer önerilerini inceler ve kabul eder. Çoğunluk yeterli sayıya ulaşırsa eğer bu değer seçilir ve kayıt işlemi yapılır.
Raft Consensus
Raft, Distributed System Architecture olarak son zamanlarda tercih edilen Readable Replica Algorthm’dir Tercih edilmesinin en büyük sebebi ise kolay anlaşılır ve iyi bir mimari tasarıma sahip olmasıdır.
Raft’ın çalışma mantığına baktığımda, Consensus’u Log Replication ile yaptığını söyleyebilirim. Bu şu anlama geliyor; Ağ üzerindeki tüm node’lar aynı log’lara sahip olmak zorunda. Node’lar üç farklı statü’ye sahip olabilirler. Master, Candidate, Follower. Application’ımız veya Client diyelim, Master Node ile iletişim halinde olacaktır. Diğer node’lar ile herhangi bir bağı bulunmamaktadır. Tüm node’lar ilk çalıştıklarında Follower olarak çalışırlar ve bir Master varmış gibi bir süre beklerler. Master olmadığını farkettiklerinde(bunu milisaniyeler ile ölçülebilecek kadar kısa bir süre olarak düşünün) Candidate olan bir kaç Node ağ üzerindeki tüm Node’lara Ping atar ve Master olmak için oy talep eder. Master veya Leader Election denilmektedir bu işleme. Candidate Node’un ping attığı Node’lar eğer henüz Candidate olmadılarsa gelen Ping’e Approve olarak dönüş yapar. Her Node kendine’de oy kullanabilmektedir(Quorum). Master olabilmek için (N/2)+1 çoğunluğunu elde eden Master olarak durumunu günceller ve diğer tüm Node’lar Follower durumuna geçerler. Aşağıda, server boyutlarına göre oy oranları ve hata toleranslarını gösteren bir tablo bulunmaktadır. Tek bir server kesinlikle önerilmemektedir.
Master, tüm node’lara ayakta olduğunu periyodik olarak bildirmesi gerekir. Node’lar bu bilgiyi edindiğinde Follower olarak kalacaklardır. Bilgi gelmediğinde Master Down olmuş demektir. Bu durumda tekrar bir Consensus kurulacak ve oylama başlayacak.
Consul’ün Alt yapısında nasıl bir algoritma olduğunu anlamanız için Paxos ve Raft Consensus Algorithm’i yüzeysel olarak anlattım.
Consul Nedir kısmına kaldığım yerden devam ediyorum…
Çeşitli Distributed System yapıların tüm uygulamanın trafiğini güvence altına alıyor. Hem sistem tarafı hem de geliştirinin üzerindeki yükü hafifletiyor aslında. Application Network’üne identity-based authorization uyguluyor ve Service-to-Service iletişiminde Encryption kullanıyor. Developer’lar için önemli olan şey aslında Agility(Çeviklik) ve Velocity(Hız) olarak düşünürsek. Consul bunu tamamen sağlıyor diyebiliriz.
Consul’ün bir çok özelliği bulunmaktadır. Service Discovery dışında, Health Checking, KV Store, Secore Service Communication, Multi Datacenter gibi özellikleri bulunmaktadır. Client, herhangi bir servisin Health durumunu düzenli olarak kontrol edebilir ve buna göre aksiyonlar alabilir. Uygulamalar; Dynamic Configuration, Leader/Master Election, Feature Flagging gibi bir çok işlemi KV Store(Key/Value) üzerinde kullanmaktadır. KV Store basic Http API’a sahiptir ve kullanımı çok kolay. Geliştirici dostu olarak adlandırılıyor.
Consul’e ait tüm service cluster’lar down olsa bile Service Discovery hayatına devam edebiliyor. Bunu Gossip protokolüne sahip Serf ile sağlamaktadır. Konu konuyu açıyor. Daha da detaylandırırsam bu yazı bitmez :) Gossip ve Serf için bir yazı daha hazırlayacağım.
Distributed Consul Architecture tarafına bakarsak eğer Bir DataCenter’da Consul kümesi bulunmaktadır. Consul’de Server ve Client olmak üzere iki tip Agent bulunmaktadır. Server Agent’lar kontrol düzlemini oluştururlar. Consul sunucuları Data Center operasyonları için kritik öneme sahiptir. Bu sunucuların tamamı Statu depolamak ve Request’lere yanıt vermekten sorumludur.Server’lar verilerin depolandığı ve replica edildiği yer olarak düşünülebilir. Veri kaybını önlemek amacıyla 3,5,7… tek sayı olacak şekilde minimum 3 Server ile çalışılması önerilir. Server, Client’tan gönderilen dataları bir araya getirerek bir Catalog oluşturur ve depolarlar. Catalog’ların yalnızca Server’da tutulmasının sebebi Raft Log Replication olmasının sağlanmasıdır. Bu şekilde Consul kümesinin Consolidated ve Consistent bir görünümü sağlanıyor. Catalog içerisinde hangi servisin kullanılabilir olduğunu, hangi loop’larda bu servislerin çalıştırıldığı, Health durumları gibi bilgiler bulunur.
Client Agent, Light-weight bir yapıya sahip olup her loop’da bulunurlar. Her loop’un ve kendisinin Health durumundan sorumludur. Client’lar bir veya birden fazla server ile iletişimde olabilirler. Bu kadar karmaşık bir yapının büyüdükçe Complex bir hal alabileceğini hepimiz biliyoruz. Consul bunun için Anti-Entropy mekanizması kullanmaktadır.
Entropy, sistemlerin giderek düzensiz bir hal alması eğilimi/ihtimali durumuna denilmektedir. Consul’e ait Anti-Entropy mekanizmalari bu ihtimale karşı koymak ve bileşenlerdeki sorunları çözmek için tasarlanmıştır.
Saturation durumunu önlemek amacıyla Cluster Size’lara göre Periyodik Anti-Entropy çalışma süreleri değişebilmektedir.
Anti-Entropy düzenli olarak çalışır ve karşılaştığı sorunları Raft Log’a kaydeder. Log’lar Raft üzerinden kontrol edilerek yazıldığı için biraz Complex bir yapıya sahiptir, bu nedenle okumalar daha esnektir. Consul, developer’lar için Default, Consistent ve stale olmak üzere üç farklı moda sahiptir. Bunlar kullanım durumlarına göre farklı datalar dönebilmektedir.
Esen kalın…
