BT'de çalışırken sistemlerin kendine has karakterleri olduğunu fark etmeye başlarsınız. Esnek, sessiz, eksantrik ve sert olabilirler. Çekebilirler veya itebilirler. Öyle ya da böyle, onlarla "pazarlık yapmak", "tuzaklar" arasında manevra yapmak ve etkileşim zincirleri oluşturmak zorundasınız.
Böylece bir bulut platformu oluşturma onuruna sahip olduk ve bunun için birkaç alt sistemi bizimle çalışmaya "ikna etmemiz" gerekiyordu. Neyse ki bir “API dilimiz” var, doğrudan ellerimiz var ve çok fazla heyecanımız var.
Bu makale teknik olarak çok ağır olmayacak ancak bulutu oluştururken karşılaştığımız sorunları anlatacaktır. Yolumuzu, sistemlerle nasıl ortak bir dil aradığımıza ve bunun sonucunda ne ortaya çıktığına dair hafif bir teknik fantezi şeklinde anlatmaya karar verdim.
Kedi'ye hoş geldiniz.
Bir yolculuğun başlangıcı
Bir süre önce ekibimiz, müşterilerimiz için bir bulut platformu başlatmakla görevlendirildi. Hizmetin yazılım kısmını uygulamak için yönetim desteğine, kaynaklara, donanım yığınına ve teknolojileri seçme özgürlüğüne sahiptik.
Ayrıca bir takım gereksinimler de vardı:
- hizmetin uygun bir kişisel hesaba ihtiyacı var;
- platformun mevcut faturalandırma sistemine entegre edilmesi gerekir;
- yazılım ve donanım: Mühendislerimizin oldukça iyi "pişirmeyi" öğrendiği OpenStack + Tungsten Fabric (Açık Contrail).
Habra topluluğunun ilgisini çekerse, ekibin nasıl oluşturulduğunu, kişisel hesap arayüzünün nasıl geliştirildiğini ve tasarım kararlarının nasıl alındığını başka bir zaman anlatacağız.
Kullanmaya karar verdiğimiz araçlar:
- Python + Flask + Swagger + SQLAlchemy - tamamen standart bir Python seti;
- Ön uç için Vue.js;
- Bileşenler ve hizmetler arasındaki etkileşimi AMQP üzerinden Kereviz kullanarak yapmaya karar verdik.
Python'u seçmeyle ilgili soruları tahmin ederek açıklayacağım. Dil şirketimizde kendine yer buldu ve onun etrafında küçük ama yine de bir kültür gelişti. Bu nedenle hizmetin bunun üzerine inşa edilmesine karar verildi. Üstelik bu tür problemlerde gelişme hızı çoğu zaman belirleyici oluyor.
O halde tanışmamıza başlayalım.
Sessiz Fatura - faturalandırma
Bu adamı uzun zamandır tanıyoruz. Her zaman yanıma oturdu ve sessizce bir şeyler saydı. Bazen kullanıcı isteklerini bize iletiyor, müşteri faturaları düzenliyor ve hizmetleri yönetiyordu. Sıradan çalışkan bir adam. Doğru, zorluklar vardı. Sessizdir, bazen düşüncelidir ve sıklıkla kendi aklındadır.
Faturalandırma, dost olmaya çalıştığımız ilk sistemdir. Ve karşılaştığımız ilk zorluk hizmetleri işlerken oldu.
Örneğin, bir görev oluşturulduğunda veya silindiğinde dahili faturalandırma kuyruğuna gider. Böylece hizmetlerle asenkron çalışma sistemi uygulanır. Hizmet türlerimizi işlemek için görevlerimizi bu kuyruğa "koymamız" gerekiyordu. Ve burada bir sorunla karşılaştık: belge eksikliği.
Yazılım API'sinin açıklamasına bakılırsa bu sorunu çözmek hala mümkün ancak tersine mühendislik yapacak vaktimiz olmadığından mantığı dışarıya çıkardık ve RabbitMQ'nun üstünde bir görev kuyruğu düzenledik. Müşteri tarafından kişisel hesabından bir hizmet üzerinde işlem başlatılır, arka uçta bir Kereviz "görevine" dönüşür ve faturalandırma ve OpenStack tarafında gerçekleştirilir. Kereviz, görevleri yönetmeyi, tekrarları düzenlemeyi ve durumu izlemeyi oldukça kolaylaştırır. Örneğin “kereviz” hakkında daha fazlasını okuyabilirsiniz: .
Ayrıca faturalandırma, parası biten projeyi durdurmadı. Geliştiricilerle iletişim kurarak, istatistikleri hesaplarken (ve tam olarak bu tür bir mantığı uygulamamız gerekiyor), durdurma kuralları arasında karmaşık bir karşılıklı ilişki olduğunu öğrendik. Ancak bu modeller gerçeklerimize pek uymuyor. Hizmet yönetimi mantığını arka uç tarafa taşıyarak bunu Kereviz üzerindeki görevler aracılığıyla da uyguladık.
Yukarıdaki sorunların her ikisi de kodun biraz şişmesine neden oldu ve gelecekte görevlerle çalışma mantığını ayrı bir hizmete taşımak için yeniden düzenleme yapmamız gerekecek. Bu mantığı desteklemek için kullanıcılara ve hizmetlerine ilişkin bazı bilgileri de tablolarımızda saklamamız gerekiyor.
Bir diğer sorun ise sessizlik.
Billy bazı API isteklerine sessizce "Tamam" yanıtını veriyor. Örneğin test sırasında söz verdiğimiz ödemeleri yaptığımızda durum böyleydi (bu konuya daha sonra değineceğiz). İstekler doğru bir şekilde yerine getirildi ve herhangi bir hata görmedik.
Kullanıcı arayüzü aracılığıyla sistemle çalışırken günlükleri incelemek zorunda kaldım. Faturalandırmanın kendisinin de benzer istekleri gerçekleştirdiği, kapsamı belirli bir kullanıcıya (örneğin admin) değiştirip bunu su parametresine ilettiği ortaya çıktı.
Genel olarak belgelerdeki boşluklara ve küçük API kusurlarına rağmen her şey oldukça iyi gitti. Nasıl yapılandırıldıklarını ve neye bakmanız gerektiğini anlarsanız, günlükler ağır yük altında bile okunabilir. Veritabanının yapısı süslü ama oldukça mantıklı ve hatta bazı yönlerden çekici.
Özetlemek gerekirse, etkileşim aşamasında karşılaştığımız temel sorunlar belirli bir sistemin uygulama özellikleriyle ilgilidir:
- bizi öyle ya da böyle etkileyen belgelenmemiş “özellikler”;
- kapalı kaynak (faturalandırma C++ ile yazılmıştır), sonuç olarak problem 1'i "deneme yanılma" dışında herhangi bir şekilde çözmek imkansızdır.
Neyse ki ürünün oldukça kapsamlı bir API'si var ve aşağıdaki alt sistemleri kişisel hesabımıza entegre ettik:
- teknik destek modülü - kişisel hesabınızdan gelen talepler, hizmet müşterileri için şeffaf bir şekilde faturalandırmaya "temsil edilir";
- finansal modül - mevcut müşterilere fatura kesmenize, zarar yazmanıza ve ödeme belgeleri oluşturmanıza olanak tanır;
- servis kontrol modülü - bunun için kendi işleyicimizi uygulamamız gerekiyordu. Sistemin genişletilebilirliği işimize yaradı ve Billy'ye yeni bir hizmet türünü "öğrettik".
Biraz zahmetliydi ama öyle ya da böyle, Billy'yle iyi anlaşacağımızı düşünüyorum.
Tungsten alanlarında yürümek – Tungsten Kumaş
Yüzlerce kabloyla noktalanmış tungsten alanları, içlerinden binlerce bitlik bilgi geçiriyor. Bilgiler sanki sihir gibi karmaşık rotalar oluşturarak "paketler" halinde toplanır, ayrıştırılır.
Bu, arkadaş olmak zorunda olduğumuz ikinci sistemin alanıdır - eski adıyla OpenContrail olan Tungsten Fabric (TF). Görevi, ağ ekipmanlarını yönetmek ve biz kullanıcılar için bir yazılım soyutlaması sağlamaktır. TF - SDN, ağ ekipmanıyla çalışmanın karmaşık mantığını kapsar. Teknolojinin kendisi hakkında iyi bir makale var, örneğin, .
Sistem, Neutron eklentisi aracılığıyla OpenStack (aşağıda tartışılmıştır) ile entegre edilmiştir.
OpenStack hizmetlerinin etkileşimi.
Operasyon departmanındaki arkadaşlar bizi bu sistemle tanıştırdı. Hizmetlerimizin ağ yığınını yönetmek için sistemin API'sini kullanırız. Henüz bize herhangi bir ciddi sorun veya rahatsızlık yaratmadı (OE'deki adamlar adına konuşamam), ancak etkileşimde bazı tuhaflıklar oldu.
İlki şuna benziyordu: SSH aracılığıyla bağlanırken örnek konsoluna büyük miktarda veri gönderilmesini gerektiren komutlar bağlantıyı basitçe "kapattı", VNC aracılığıyla ise her şey doğru şekilde çalıştı.
Soruna aşina olmayanlar için oldukça komik görünüyor: ls /root düzgün çalışıyor, örneğin top tamamen "donuyor". Şans eseri daha önce de benzer sorunlarla karşılaştık. Hesaplama düğümlerinden yönlendiricilere giden rotadaki MTU'nun ayarlanmasıyla karar verildi. Bu arada bu TF'nin sorunu değil.
Bir sonraki sorun hemen köşedeydi. "Güzel" bir anda, yönlendirmenin büyüsü ortadan kayboldu. TF, ekipmandaki yönlendirmeyi yönetmeyi bıraktı.
Openstack ile yönetici düzeyinde çalıştık ve ardından gerekli kullanıcı düzeyine geçtik. SDN, eylemlerin gerçekleştirildiği kullanıcının kapsamını "ele geçiriyor" gibi görünüyor. Gerçek şu ki, TF ve OpenStack'i bağlamak için aynı yönetici hesabı kullanılıyor. Kullanıcıya geçiş aşamasında “sihir” ortadan kalktı. Sistemle çalışmak üzere ayrı bir hesap oluşturulmasına karar verildi. Bu, entegrasyon işlevselliğini bozmadan çalışmamıza olanak sağladı.
Silikon Yaşam Formları - OpenStack
Tuhaf şekilli bir silikon yaratık, tungsten alanlarının yakınında yaşıyor. En önemlisi, bizi tek bir vuruşla ezebilecek büyümüş bir çocuğa benziyor, ancak ondan gelen bariz bir saldırganlık yok. Korku yaratmaz ama büyüklüğü korku uyandırır. Etrafta olup bitenlerin karmaşıklığı da öyle.
OpenStack platformumuzun temelidir.
OpenStack'in birçok alt sistemi mevcut olup, bunlardan şu anda en aktif olarak Nova, Glance ve Cinder'ı kullanıyoruz. Her birinin kendi API'si vardır. Nova, bilgi işlem kaynaklarından ve örneklerin oluşturulmasından sorumludur; Cinder, birimlerin ve bunların anlık görüntülerinin yönetilmesinden sorumludur; Glance, işletim sistemi şablonlarını ve bunlar üzerindeki meta bilgileri yöneten bir görüntü hizmetidir.
Her hizmet bir konteynerde çalışır ve mesaj komisyoncusu "beyaz tavşan" - RabbitMQ'dur.
Bu sistem bize en beklenmedik sıkıntıyı yaşattı.
Ve sunucuya ek bir birim bağlamaya çalıştığımızda ilk sorunun gelmesi uzun sürmedi. Cinder API'si bu görevi gerçekleştirmeyi açıkça reddetti. Daha doğrusu OpenStack'in kendisine inanırsanız bağlantı kuruluyor ancak sanal sunucunun içerisinde herhangi bir disk cihazı yok.
Biz de yoldan sapmaya karar verdik ve aynı işlemi Nova API'den talep ettik. Sonuç, cihazın doğru şekilde bağlanması ve sunucudan erişilebilir olmasıdır. Görünüşe göre sorun, blok depolama Cinder'a yanıt vermediğinde ortaya çıkıyor.
Disklerle çalışırken bizi başka bir zorluk bekliyordu. Sistem biriminin sunucuyla bağlantısı kesilemedi.
OpenStack yine bağlantıyı yok ettiğine "yemin ediyor" ve artık hacimle ayrı ayrı doğru şekilde çalışabilirsiniz. Ancak API kategorik olarak diskte işlem yapmak istemedi.
Burada özellikle kavga etmemeye, hizmetin mantığına bakışımızı değiştirmeye karar verdik. Bir örnek varsa, bir sistem biriminin de olması gerekir. Bu nedenle kullanıcı, "sunucuyu" silmeden sistem "diskini" henüz kaldıramaz veya devre dışı bırakamaz.
OpenStack, kendi etkileşim mantığına ve süslü API'sine sahip oldukça karmaşık bir sistem kümesidir. Oldukça ayrıntılı belgeler ve elbette deneme yanılma yoluyla bize yardımcı oluyor (onsuz nerede olurduk).
Test sürüşü
Geçen yıl Aralık ayında bir test lansmanı gerçekleştirdik. Asıl görev, projemizi savaş modunda teknik ve kullanıcı deneyimi açısından test etmekti. Seyirci seçici olarak davet edildi ve test kapatıldı. Ancak web sitemizde teste erişim talebinde bulunma seçeneğini de bıraktık.
Testin kendisi de elbette komik anlardan yoksun değildi çünkü burası maceralarımızın daha yeni başladığı yer.
İlk olarak, projeye olan ilgiyi biraz yanlış değerlendirdik ve test sırasında hızlı bir şekilde bilgi işlem düğümleri eklemek zorunda kaldık. Bir küme için yaygın bir durum, ancak burada da bazı nüanslar vardı. Belirli bir TF sürümüne ilişkin belgeler, vRouter ile çalışmanın test edildiği çekirdeğin belirli sürümünü belirtir. Daha yeni çekirdeklere sahip düğümleri başlatmaya karar verdik. Sonuç olarak TF, düğümlerden rota alamadı. Çekirdekleri acilen geri almak zorunda kaldım.
Bir diğer merak konusu ise kişisel hesabınızdaki “şifre değiştir” butonunun işlevselliği ile ilgilidir.
Oturumlarla çalışmamak için kişisel hesabımıza erişimi düzenlemek için JWT'yi kullanmaya karar verdik. Sistemler çeşitli ve geniş bir alana dağılmış olduğundan, oturumları faturalandırmadan ve OpenStack'ten bir jetonu "sardığımız" kendi jetonumuzu yönetiyoruz. Şifre değiştirildiğinde, kullanıcı verileri artık geçerli olmadığından ve yeniden yayınlanması gerektiğinden jeton elbette "kötüleşir".
Bu noktayı gözden kaçırdık ve bu parçayı hızla bitirmek için yeterli kaynak yoktu. Testi başlatmadan hemen önce işlevselliği kesmek zorunda kaldık.
Şu anda şifre değiştirilmişse kullanıcının oturumunu kapatıyoruz.
Bu nüanslara rağmen testler iyi geçti. Birkaç hafta içinde yaklaşık 300 kişi uğradı. Ürüne kullanıcıların gözüyle bakabildik, çalışırken test edebildik ve yüksek kaliteli geri bildirimler topladık.
Devam edecek
Birçoğumuz için bu ölçekteki ilk proje. Ekip olarak nasıl çalışılacağı ve mimari ve tasarım kararlarının nasıl alınacağı konusunda çok sayıda değerli ders öğrendik. Az kaynakla karmaşık sistemlerin nasıl entegre edileceği ve üretime nasıl aktarılacağı.
Elbette hem kod anlamında hem de sistem entegrasyonunun arayüzlerinde üzerinde çalışılacak bir şeyler var. Proje oldukça genç ama biz bunu güvenilir ve kullanışlı bir hizmete dönüştürme konusunda çok istekliyiz.
Sistemleri zaten ikna edebildik. Bill, dolabındaki sayma, faturalandırma ve kullanıcı isteklerini görev bilinciyle yerine getiriyor. Tungsten alanlarının "sihri" bize istikrarlı iletişim sağlar. Ve yalnızca OpenStack bazen kaprisli davranarak "WSREP henüz düğümü uygulama kullanımı için hazırlamadı" gibi bir şey bağırır. Ama bu tamamen farklı bir hikaye...
Yakın zamanda hizmeti başlattık.
Tüm detayları sitemizden öğrenebilirsiniz .
HİS Geliştirme Ekibi
Faydalı linkler
OpenStack
Tungsten Kumaş
Kaynak: habr.com