English
Bu yazı I-Delta yazı serisinin 7. bölümüdür. Tüm yazı serisi için; 1.bölüm, 2. bölüm , 3.bölüm, 4.bölüm, 5.bölüm, 6. bölüm, 7. bölüm, 8. bölüm.
Click here for the English version.
I-DELTA, birlikte çalışabilir bir DLT tabanlı platform oluşturmayı amaçlamaktadır. Bu amaçla, bağımsız ve egemen bir zincir, diğer blockchain'lerle iletişim kurma yeteneği sağlar. Bilgi Görünümünün amacı, veri noktalarının ve hizmetlerin semantik açıklaması için kullanılan yöntemle birlikte, sistem/platformun açıklaması için kullanılan bilgi modelini tanımlamaktır. Bilgi Görünümü, güvenlik, üyelik, birlikte çalışabilirlik, konsensus ve geliştirme kiti konuları üzerinden analiz edilebilir.
Güvenlik
I-DELTA, yerel/global güvenlik modeli altında çalışacaktır. Bu güvenlik modeli, aşağıdaki şekilde görüldüğü gibi çalışır. I-DELTA Güvenlik Diyagramı
Güvenlik, dört farklı bölümden oluşacaktır. Diğer Zincirler, I-DELTA ağındaki blockchain'lerdir. Diğer Zincirler, kendi kuralları olan bağımsız durum makineleridir. Diğer Zincirlerin blok üreticileri, Koleksiyonculardır. Koleksiyoncular, işlemleri doğrulamak ve buna göre bloklar oluşturmak için Diğer Zincirlerden veri toplarlar. Doğrulayıcılar, değişiklikleri doğrulamak için Koleksiyonculardan blokları toplarlar. Eğer Doğrulayıcılar blokları doğrularsa, bloklar Merkezi Olmayan Web'de güncellenecektir. Doğrulayıcılar, kötü amaçlı reddetmeleri önlemek için Diğer Zincirlerden blokları reddedebilir. Validator shuffling ve Master Validator'lar kullanılacaktır. Validator shuffling, Diğer Zincirlerden gelen blokların kötü amaçlı reddedilmesini en aza indirmek için Validator'ları farklı Koleksiyoncularla eşleştirecektir. Master Validator'lar, anomalileri önlemek için Validator'ların etkinliklerini sürekli olarak kontrol edecektir. Koleksiyoncular, ebeveyn zincir Merkezi Olmayan Web'in çocukları olarak hareket edecektir. Bu güvenlik sistemi, projeye paylaşılan bir güvenlik modeli sağlayacaktır. Diğer Zincirler, Validator'lar aracılığıyla Merkezi Olmayan Web'in bu güvenlik sisteminden faydalanacaktır.
İnsanlar, zincirler arası iletişimi etkili hale getirecek bir merkez oluşturabileceklerdir. Merkezler, diğer blockchain'lere bağlanmak için kendi egemen blockchain'lerine sahip olacaklardır. Bu merkezler, Şekil 1'deki Dağıtık Web tarafından doğrulanacaktır. Merkezlerin çalışma prensibi Şekil 2'de gösterilmektedir.
Merkezler, birden fazla zinciri bağlamanın verimliliğini artıracaktır. Her merkezin kendi yönetimi ve kuralları olacaktır.
Blockchain'ler arası iletişim, Diğer Zincirler arasında bir mesajı hedef alarak gerçekleştirilecektir. Zincir A, iletişim kurmak için Zincir B içindeki bir akıllı sözleşmeyi çağırabilecektir. Güvenlik sistemi sayesinde, I-DELTA birlikte çalışabilirliği güvence altına almak için iki farklı mekanizma kullanabilecektir. Şekil 1'de açıklanan Validator'lar aracılığıyla Diğer Zincirler arasında paylaşılan güvenlik, Diğer Zincirler arasında güven sağlar. Her Diğer Zincir, eşit düzeyde bir güvenliğe sahip olacak ve Merkezi Olmayan Web, paylaşılan güvenlik yardımıyla iletişime izin verecek kadar güvenli olacaktır. Diğer Zincirler arasındaki kötü amaçlı iletişimi önlemek için, Validator'lar karıştırılacak ve Diğer Zincirler'e rastgele atanacaktır. Bu yaklaşımla, kötü amaçlı iletişim sistem üzerinden en aza indirilecektir. Ek olarak, Master Validator'lar, kötü amaçlı iletişimin ortadan kaldırılmasını sağlamak için Validator'ların ve Diğer Zincirler'in etkinliklerini kontrol edecektir. Birlikte çalışabilirlikte bu güvenlik önlemlerini kullanarak, Merkezi Olmayan Web, paylaşılan güvenlik ve Master Validator'lar kullanarak kötü amaçlı iletişimi geri alabilecektir.
Güvenilirlik ve Teknik Yönetim Perspektifi
Güvenilir bir hizmet sunma temel gerekliliği, şu istenmeyen sonuçlar dizisine dönüşebilecek bir süreliğine hizmet kesintisi riskini beraberinde getirir:
- Veri kaybı
- Gelir kaybı
- Azalan verimlilik
- Hizmetin itibarı - kaybedilen iş fırsatları
- Hizmetin geri kazanılması için gereken maliyet ve süre (yıllık olarak artmaktadır)
Bir sistemin veya hizmetin kesintisiz olarak gerekli performansı sağlamasını garanti etmek için, yönetim, izleme ve bakımı göz önünde bulundurarak geliştirdiğimiz kendi GPC Çerçevemizi kullanırız. GPC İŞ'lerinin tanımlanması ve planlanması, buradaki sistem yönetiminin çekirdeğidir. Her durumda GPC İŞ, bir değişiklik talebine karşılık gelir. Planlanan görevler şunlar olabilir:
- otomatik - hizmetin kapatılması, çevrimdışı yedekleme, anlık görüntü oluşturma ve hizmetin yeniden başlatılması, beklemedeki pasif veri depolamanın senkronizasyonu.
- pasif - hizmetin yöneticisi için bir bakım penceresi olarak
Birincil amaç, bağımlı uygulamalara erişim sağlamak ve bir sağlayıcının veritabanını kapatırken diğerinin veri yükleme sürecinde olduğu durumlar gibi durumları ortadan kaldırmaktır.
Otonom görevleri gerçekleştirmek için yazılım bileşenleridir. İzleme ajanları, herhangi bir hizmete atanabilir ve bağımlı hizmetlerin üst ve alt seviyeleri için çıktılarını tanımlayabilir. Sistem performansını daha da iyileştirmek için farklı veri yorumlamalarına sahip bir dizi izleme politikası tanımlanabilir. API kullanarak harici uygulamalar için uzaktan iletişim kurabilirler.
Pasif izleme, bir span portu veya musluk üzerinden ağ trafiğini sessizce analiz ederek uç noktaları ve trafik modellerini belirler. Ek ağ trafiği oluşturmaz ve uç noktalarla doğrudan etkileşimle kritik süreçleri bozma riski neredeyse yoktur. Ancak, pasif izleme, her varlık için ağ trafiği üretilmesini beklemesi nedeniyle varlık verilerini toplamada daha fazla zaman alabilir ve böylece tüm varlık profillerini oluşturabilir. Ayrıca, bazı durumlarda, span portları tüm ağ alanlarında mevcut olmayabilir, bu da tüm OT ortamında trafiği pasif olarak izleme yeteneğini sınırlayabilir.
Aktif izleme, ağa test trafiği göndererek ve temas ettiği uç noktaları anketleyerek çalışır. Aktif izleme, cihaz adı, IP ve MAC adresi, NetFlow veya syslog verileri ile birlikte, marka ve model, firmware sürümleri, yüklü yazılım/sürümler ve işletim sistemi yama seviyeleri gibi daha ince yapılandırma verilerinin toplanmasında çok etkili olabilir. Paketleri doğrudan uç noktalara göndererek, aktif tarama veri toplamada daha hızlı olabilir, ancak bu, uç noktalara uyumsuz sorgular göndererek veya daha küçük ağları trafikle doyurarak uç nokta arızalarının riskini de artırır. Ayrıca, aktif tarama genellikle ağı 24/7 izlemez, bu nedenle geçici uç noktaları veya yalnızca dinleme modundaki cihazları tespit etmeyebilir.
Sürekli çalışması gereken hizmetler için, öyle denilen bir iyileştirme mekanizması olmalıdır. Bu, günlükleri toplayan ve hizmet arızalarının oluşumlarını doğrulayan bir izleme sisteminden oluşur. Bir arıza tespit edildiğinde, belirli hataya bağlı olarak otomatik olarak bir geri yükleme protokolü çalıştırılır. Geri yükleme protokolleri, hizmetleri başka bir sunucuya aktarmayı, basit bir yeniden başlatmayı veya sorumlu yöneticilere bildirimde bulunmayı içerebilir.
Kompleksite perspektifinden iyileştirme mekanizmaları üç seviyeye ayrılabilir:
- temel kurallar şeklinde olup, yöneticilerin müdahalesini gerektirebilir
- orta seviye, arızaların metriklerini ve görselleştirmesini gösterir
- gelişmiş seviye, kök neden otomatik olarak belirlenir
Yüksek erişilebilirlik
Bu kavram, paralel veya yüzen IP'lerle trafik yönlendirmeye yardımcı olarak birden fazla sunucuyu çalıştırarak veya sistem, tek bir arıza noktasına dayanmamalarını sağlar. Yedek sunuculara geçiş sorunsuz olmalıdır. Veri replikasyonu, sistem arızası durumunda kurtarma olarak hizmet verir.
Docker iletişimi
Özellikle I-DELTA çerçevesi için Docker iletişimi, birden fazla hizmet arasındaki ağ katmanlarını basitleştirmek için yararlı olabilir. Docker konteynerları, bir ana makine üzerinden birbirleriyle ve dışarıyla iletişim kurmalarına izin verir. Docker, belirli kullanım durumlarına uygun olan birçok farklı ağ türünü destekler.
Örneğin, tek bir Docker konteynerinde çalışan bir uygulama oluşturmak, birden fazla konteynerde veritabanı, uygulama ve yük dengeleyicileri içeren bir web uygulaması kümesiyle karşılaştırıldığında farklı bir ağ kurulumuna sahip olacaktır. Ek olarak, dışarıdaki istemcilerin web uygulaması konteynerine erişmesi gerekecektir.
Sürekli dağıtım için öncelikle bir plan olması gerekir. Verilen projenin emekliliğini de içeren yeni güncellemeleri benimseme için bir zaman çizelgesi gibi. Bu amaçla, mimariyi gösteren bir dağıtım diyagramı (UML türü) tanımlanmalıdır. Uygulamaların manuel güncellemeleri zaman alıcı, tekrarlayan ve insan hatalarına açıktır, bu nedenle otomatik bir süreç önerilir. Özellikle, sürüm sürecinde darboğazları önlemek istediğimizde.
Dağıtmadan önce şunları göz önünde bulundurmalıyız:
- Etkisi ne olacak?
- Direnç bekliyor muyuz?
- Dağıtım başarısız olursa etkisi ne olacak?
GPC Çerçevesi tarafından desteklenen dağıtım senaryoları
Not: GPC Master, merkezi bir GPC ajanı olarak çalışır. Ana veritabanına erişimi vardır ve tüm ajanlardan ve ajan kümelelerinden bilgi içerir.
I-DELTA projesi için dağıtım seçeneklerini değerlendirirken, Kubernetes'in geleneksel dağıtımlara göre büyük bir avantajı vardır. Bu avantaj, trafiğin ve kaynak kullanımının miktarına uyum sağlama yeteneğidir. Uyum, küme düğümlerinin ve hatta podların otomatik ölçeklendirilmesiyle sağlanır. Dağıtımın ölçeklendirildiğini garanti etmek için, Kubernetes, CPU iş yüküne, bellek tüketimine veya diğer metriklere yanıt veren Yatay Pod Otomatik Ölçekleyici API nesnesini kullanır.
Bu yazı I-Delta yazı serisinin 7. bölümüdür. Tüm yazı serisi için; 1.bölüm, 2. bölüm , 3.bölüm, 4.bölüm, 5.bölüm, 6. bölüm, 7. bölüm, 8. bölüm.
Click here for the English version.