Vmware

Kafka Terminolojisi ve Mimarisi

Apache Kafka son yıllarda başta microservice olmak üzere yeni nesil mimarilerin ve büyük oranda veri ve/veya olay akışlarıyla çalışan uygulamaların temel bileşenlerinden biri haline gelmiş bir yapıdır.Bu yazı serisinde ilk önce Kafka’nın terminolojisi, mimarisi ve nasıl çalıştığından bahsedip, bir sonraki yazılarımda sırayla kurulum ve bazı iyi uygulama örneklerine değineceğim.

Kafka dağıtık, kolay ölçeklenebilir, hataya dayanıklı ve sürdürülebilirliği yüksek bir veri/olay akış aracıdır. Çok büyük miktarda veriyi eş zamanlı karşılamasının yanında veriyi üreten kaynaktan okuyup arkada tüketecek sisteme 10ms’nin altında aktarabilecek bir kapasiteye sahiptir. Peki, Kafka ne gibi senaryolarda kullanılmaktadır;

  • Büyük ölçekte IoT metriklerinin veya uygulama loğlarının toplanacağı, yüzlerce hatta yüz binlerce kaynaktan eş zamanlı gelen verilerin yazılması, saklanması ve ilgili uygulamaların kullanabilmesi için verilerin sunulabilmesi.
  •  Farklı sistemlerin bir birleriyle konuşabilmesi için ortak ara yüz sunması; bir uygulama eğer birden fazla uygulamayla iletişime geçmesi gerekiyorsa her biriyle olan iletişimi için tek tek entegrasyon yazılması gerekmektedir. Bu hem iş yükü olarak hem de mimari olarak çok tercih edilmediği gibi, değişiklikler veya sorunlar esnasında ciddi darboğaza sebep olmaktadır. Bunun yerine uygulamalar mesajlarını Kafka’ya yazıp, bu mesajı tüketecek uygulamaların da direk Kafka’dan bu mesajları okuması, hem karmaşıklığı oradan kaldıracak hem asenkron bağlantı sayesinde uygulamaların genel performansı olumlu olarak artacak hem de geliştirilecek entegrasyon sayısı ciddi anlamda azalacaktır.
  • Canlı veri akışının toplanması ve analiz edilmesi; mesela bir web sitesinde kullanıcıların gezinti verilerinin toplanıp anlık önerilerin yaratılması için tüm gezinti metriklerinin kafka’da toplanıp kafka üstünde analiz edilmesi.

Kafka’nın ne olduğu ve amacını anlattığımıza göre terminolojisinden ve mimarisinden bahsetmeye başlayabiliriz. En başta biraz karışık gelse de Kafka oldukça basit bir yapıya sahiptir, özellikle daha önceden bir MQ veya benzer bir Event-streaming servisiyle çalıştıysanız ilişki kurmanız kısa zaman alacaktır.

Broker: Kafka sistemlerinin en temel bileşenidir, Kafka kümesinde çalışan her bir sunucu/servise broker denir. Broker’lar fiziksel olarak kurulu oldukları sunucuya bağlıdırlar ama bir broker kendi üstünde olmasa bile kümede ki tüm topic ve partition’lardan haberdardır. Broker’lar hem producer hem de consumer’lar için bağlantı noktası olarak görev alırlar. Broker’ların her biri eşsiz bir sayı ile temsil edilir(Örnek: 101,102,103 gibi).

Broker discovery/bootstrap server: Consumer veya Producer’lar sadece bir broker üzerindeki bootstrap servisine bağlanarak tüm kümede bulunan diğer broker’lar, topic’ler ve partition’ların durumunu ve bağlantı noktalarını öğrenebilirlerler. Bu bilgileri bootstrap server metadata olarak istemcilere sunmaktadır.

Topic: Verilerin yazıldığı, yaratıldığı anda tüm brokerlar tarafından erişilebilir olan, kafka’nın veri tabanları veya MQ’larda bulunan kuyruklara benzeyen yapısıdır. Topic’ler istendiği kadar yaratılabilir ve mantıksak bir kavramdır. Topic isimleri harf, rakam ve bazı özel karakterlerden oluşabilir.

Partition: Verilerin yazıldı, her broker’ın kendisine özel olan ve bir topic’e bağlı fiziksel disk üzerindeki alanı temsil eder. Bir topic’e ait birden fazla partition olabilir, her partition’nın 20Mb/s’lık okuma ve yazma limiti bulunmaktadır ve partition bağlı olduğu topic’e özel 0,1,2,3… gibi rakamlar şeklinde temsil edilir.

Veri Partition’a bir kere yazılır ve belli bir süre boyunca saklanır, Partition’a yazılan veri silinemez. Topic’ler yaratılırken kaç adet partition ile yaratılacağını belirleyebiliriz. Kafka broker sayısına göre partition’ları küme içerisinde dağıtır. Bu konuda ki iyi uygulamalardan biri broker sayısı veya onun katları kadar partition yaratılması yönündedir.

Replication: Yukarda da bahsettiğim üzere Partition’lar tüm küme tarafından erişilebilseler bile (Broker Discovery/bootsrap server maddesine bakınız.)üzerlerinde bulundukları fiziksel diske bağımlıdırlar eğer broker bir sebepten dolayı devre dışı kalırsa üzerinde bulunan partition’lara erişilemez. Bu da veri kaybına sebep olabilir. Bunu önlemek için Kafka, replication mekanizmasını kullanır. Bir topic yaratılırken her partition’nın kaç adet kopyası olacağını belirleyebiliriz.

Mesela 3 partition ve 2 replication factore sahip bir topic yapısı aşağıdaki gibi gözükmektedir.

Replication of Kafka

Son önemli bir noktaysa partition’ların kopyalarını yarattığımız zaman sadece bir tanesi producer’lar tarafından yazılabilir, t anında yazılabilir olan partition’a leader diğerlerine ISR(in-sync-replication) denmektedir.

Bir partition’nın birden fazla replication’ı olabilir ama sadece bir adet aktif leader’ı vardır.

Offset: Partition ve topic konularını kapatmadan önce önemli bir kavramdan daha bahsetmek gerekli, offset’ler partition özelinde olup, veriler her partition’a yazılırken bir identity number atanır, bu sayede veriler hem partition’a yazıldığı sırayla okunabilir hem de consumer’lar bir partition’da okuma yaparken hangi mesajda kaldıklarını hatırlayabilirler.

Offset sayısı 0’dan başlar ver sonsuza dek devam edebilir, her mesaj yazıldığında yeni mesaja bir sonraki numara atanır.

Offset’ler partition özelinde olduğundan dolayı bir topic’e sahip tüm partition’ların offset sayıları farkılır sadece bir partition’nın leader ve onun replica’ları aynı offset’e sahiptir.

Topic Offsets

Producer: Kafka terminolojisine göre mesaj(log) yaratan ve ilgili topic’e yazan uygulama/sistemlere verilen isimdir. Producer’lar bootstrap server sayesinde tüm broker, topic ve partition’ların listesine erişebilirler bu sayede mesajı nereye yazacağını ve nasıl yükü dağıtacağını kendisi karar verebilir.

Producer’lar her mesajı yazarken yazılım işleminden sonra onay(ACK) talep edebilirler. Kafka şu anda 3 tip ACK desteklemektedir, bunlar;

  • ACK = 0; yani mesajı yazdıktan sonra cevap beklememesi, bunun handikabı veriyi producer’ı broker’a bıraktıktan sonra bir aksilik olur ve yazamazsa producer bundan haberdar olmayacak ve veri kaybına sebep olabilir.
  • ACK = 1; Producer leader partition’a mesaj yazıldığında ACK cevabını alır. Veri kaybı riski görece olarak düşük olsa da leader’in ISR partitionlara kopyalaması bitmeden ACK verildiği için eğer tam bu esnada leader partition bulunduğu broker devre dışı kalırsa veri kaybı olabilir.
  • ACK = all; Producer hem leader hem de tüm ISR’e yazma işlemi bitmeden ACK cevabını almaz bu sebepten dolayı veri kaybı riski en düşük olan model ama Producer tarafı için cevabı beklemesi gerektiğinden performansı en düşük olan seçenektir.

Uygulamanızın kritikliği, mesaj zincirinin bozulması durumundaki etkisi gibi konuları göz önüne alınarak karar verilmesi gerekmektedir.

Message Key: Uygulamaların(Producer) Kafka’ya yazdığı mesajlar 3 parçadan oluşmaktadır; zaman damgası, mesajın içeriği ve message key. Message key her mesaj için ayrı oluşturur ve aynı key’e sahip mesajlar aynı partition’lara yazılırlar. Bunu Producer eğer belirtmezse, kafka kendisi her mesaj için yaratıp kendisi bir partition’a atayabilir veya alternatif olarak belli tip bir mesajın aynı partition’a yazılmasını istiyorsak özelliklede okuma sırasının her zaman doğru olmasını bekliyorsak message key’i elle de atayabiliriz.

Consumer: Kafka’dan verileri okuyan sistemlere verilen isimdir, aynı producer’lar gibi bootstrap serverüzerinden tüm Kafka kümesine erişebilir ve kendi load balance’ını yapma yetisine sahiptir. Consumer’lar partitionlardan verileri sırayla okur, burada dikkat edilmesi gereken nokta Kafka’ya mesajlar yazılırken birden fazla partition’a yazıldığından dolayı Consumer’lar aynı sırayla partitionlara erişmediklerinden dolayı Kafka’ya yazılma sırasından farklı olarak okunabilir. Mesajlar sadece partition’lar içerisinde sıralıdır, partition’lar bir birinden farklı sırada okunabilir.

Consumer Group: Aynı Topic’i okuyan birden fazla consumer’ın olması durumunda aynı mesajın tekrar tekrar okunmasının önüne geçmek için Consumer Group kullanılır. Consumer group içerisinde bulunan tüm consumer’lar en az bir partition’a atılır ve aynı grup içerisindeki diğer consumer aynı partitiona atanmaz. Böylelikle tekrarlı okumaların önüne geçilir.

Consumer Group içerisinde hangi consumer’ın hangi partition’la eşleştiğini, gruba yeni consumer geldiğinde veya çıktığında partition’ların tekrar dağıtılması işlemini Consumer coordinatör denilen, Kafka’nın broker’larından birini bu rol için leader seçtiği bir node üzerinde olur.

Consumer Group kullanımıyla ilgili iyi uygulamalardan biri de Consumer sayısının asla Partition sayısını geçmemesidir. Consumer group her bir partition’ı sadece bir consumer’a atayacağından dolayı fazla consumerlar boşta kalacaktır.

Consumer Group

Consumer group konusunu bitirirken __consumer_offset isimli topic’den bahsetmem gerekir. Bu topic kafka tarafından yaratılan ve yönetilen bir topictir ve consumer’lar bir partition’dan her okuma yaptıklarında hangi offset’te kaldıklarını burada tutuluyor. Consumer group’a yeni bir üye katıldığında veya bir consumer kesinti yaşayıp tekrar kafka’ya bağlandığında buradan nerede kaldığını hatırlayarak devam ediyor. Kafka kümesini ilk kurduğunuzda __consumer_offset’in mutlaka minimum 3 node’a replice edilmesini ayarlamanız gerekmektedir, aksi durumda __consumer_offset’in leader partition’larını tutan broker’ı kaybetmeniz durumunda servisiniz duracaktır.

Consumer delivery semantics: Consumer’ın ne zaman offset’i commit ettiğini belirler.

  • At most once: Offset consumer tarafından okunur okunmaz commit edilir, eğer consumer tarafında mesaj okunduktan sonra işlemlerde sorun oluşursa veri kaybı oluşabilir
  • At least once: Offset’in commit edilmesi consumer okuduğu mesajı işledikten sonra yapılır, veri kaybı riski az olmasına rağmen mesaj birden fazla kere okunabilir.
  • Exactly once: Daha çok Kafka’dan kafka’ya mirrormaker gibi süreçlerde kullanılır.

Kafka terminolojisinden bahsederken fark etmiş olduğunuz üzere kafka ciddi bir metadata yönetimi yapmakta, tüm bileşenlerinin bilgilerini ve yetkileri bir yerde saklamalı aynı zamanda küme içerisinde ki leader/follower yapısını bir şekilde takip edip devre dışı kalan veya yeni eklenen broker’lara göre kümeyi dinamik olarak ayarlayabilmelidir. Kafka mevcut versiyonu itibariyle bu rolleri Zookeeper ile yapmakta ama yakın gelecekte planlanan versiyonlarında Zookeeper yerine kendi iç metadata veri tabanını kullanması planlanmaktadır.

Zookeeper; özellikle büyük veri projeleri başta olmak üzere birçok açık kaynak projesinde kullanılan, dağıtık, key-value veri saklama yeteneğine sahip açık kaynaklı bir servistir. Zookeeper kafka için aşağıdaki rolleri üstlenir;

  • Kafka kümesinin takibi; Zookeeper kümede bulunan tüm broker’ları heartbeat servisleriyle izler ve bir tanesine erişilememe durumunda broker listesinden çıkartır. Böylelikle bootstrap servisi üzerinden producer ve consumer’lar bu broker’ı göremezler. Aynı şekilde yeni bir broker’ın eklmesi durumunda tüm kümeye bildirimini yapar.
  • Controller seçimi: Kafka broker’larından biri kümedeki tüm partitionların leader/follower ilişkini controller yönetir. Bir broker devre dışı kaldığında onun üzerindeki leader partitionlara sahip hangi replicaların leader olacağını seçer. Bu role sahip broker’ın cevap verememe durumunda Zookeeper yeni bir controller seçer
  • Topic konfigürasyonlarının ve ACLs’lerin tutulması: Kümede hangi topic’ler, kaç adet partitiona sahip, partition durumları, replicationların durumu ve yerlerinin bulunduğu metadataları tutar ve yönetir. Aynı zamanda kullanıcıların broker’lar ve topic’ler üzerindeki yetkileride burada tutulmaktadır.
  • Kotalar: Topic’ler ve partitionlar ile kullanıcıların yazma/okuma kota bilgilerini burada tutar.

Zookeeper Kafka’dan ayrı bir servistir ve ayrı olarak konumlandırılması ve planlanması gerekmektedir. Zookeeper leader follower mekanizmasıyla çalışmaktadır, yani zookeeper kümesindeki bir sistem tüm işlemleri, değişiklikleri ve koordinasyonu üstleniyor diğer nodelarsa onu takip ediyorlar. Kümede lider seçimi çoğunluk oyuna göre yapılmaktadır, bu sebepten dolayı Zookeeper kümesinin node sayısının 1,3,5,7… gibi tek sayılardan oluşması gerekmektedir.

Yukarda konuştuklarımızı özetlerse Kafka yapısı aşağı yukarı aşağıdaki gibidir.

Genel yapı

vRealize Automation 7

Vmware 2015 yılını bitirirken bize erken bir yılbaşı süprizi yapıp vRealize Automation 7 ürününü piyasaya çıkartmayı planladığını açıkladı. Yeni versiyonda başta mimarisi olmak üzere radikal değişikliklere gitmiş bulunmaktadır. Bunlardan en başta göze batanları ayrı bir identity server yerine vRA appliance ve identity server tek bir sunucu olarak gelmektedir, böylelikle hem daha kolay bir kurulum elde edilmiş hem de ürünü HA hale getirmek kolaylaşmıştır.

Öteki önemli değişimse vRA 7 ortamının kurulum adımlarıdır, vCAC 5.x’dan beri kullanmaktayım ve her zaman kurulumu tam bir sinir harbi olmaktaydı. vRA 7’inin kurulumuna başlarken ürünün beta olmasından kaynaklı çok ciddi sorunlar yaşayacağımı sanırken inanılmaz kolay ve hiç sorunsuz bir kurulum gerçekleştirdim. Açıkcası şaşkınlığımı hala atlatabilmiş değişim 🙂

Continue reading

vRA Ek Endpoint Tanımlamak

Geçen gün bir arkadaşımın vRealize Automation center’a ikinci bir vCenter endpoint olarak nasıl eklenir diye soru sorması üzerine bu yazıyı yazmaya karar verdim eminim bu kadar temel bir ihtiyaca hepimiz ihtiyaç duymaktayız.

vRealize Automation Center herhangi bir kaynağa(vsphere,hyper-v,aws,orchestrator….gibi) endpointler üzerinden ulaşmaktadır. Siz bir talepte bulunduğunuz zaman IaaS server ilgili kaynağın proxy’si üzerinden bağlanır. Her kaynak farklı bir proxy’e sahiptir.Proxy’ler IaaS üzerinde veya başka bir sunucuda olabileceği gibi bir sunucuda birden fazlada Proxy bulunabilir. İlk önce proxy’i kuracağımız sunucu üzerine “IaaS installer’ı” indirelim ve Administrator olarak çalıştıralım.

Continue reading

SRM – Recovery Test/Cleanup/Cancel Tuşunun Gelmemesi

Bundan bir kaç gün SRM ile Recovery Planlarını Test ederken bazı sıkıntılar yüzünden testi iptal etmek zorunda kaldım tam bu esnada SRM servisinin durması üzerine garip bir sorunla karşılaştım. SRM servisi durunca vCenter’ın tuttuğu Recovery tasklerinin state’i ile SRM’in stateleri tutmadığından dolayı aşağıda ki ekran görüntüsünde ki gibi bir durum oluştu.

SRM - Recovery Test

Continue reading

vRealize Log Insight – Netapp Content Pack Upload Error

Bu yazımda yakın zaman da vRealize Log Insight ve Netapp entegrasyonu kurmaya çalışırken yaşamış olduğum bir problem ve çözümünden bahsedeceğim. vRealize Log Insight’a her hangi bir content pack’i eklemek oldukça kolay ve sıradan bir işlemdir.

Kısacana content pack eklemekten bahsetmem gerekirse aşağıda ki adımları izlemeniz yeterli oluyor:

Continue reading