Suning'in otomatik konfigürasyon işlemi ve devasa sunucuların bakımı uygulaması
İş hacmindeki artışla, sunucunun standart taraması ve çekirdeğin toplu olarak yükseltilmesi ile, Double 11 promosyonuna hazırlanırken, işlemler ve bakım, çok sayıda sistem genişletme, konfigürasyon, global değişken ayarlarına ve diğer işlemler kademeli olarak normal hale gelecektir. Binlerce ana bilgisayarın işletimi ve bakımı artık bastion ana bilgisayar sistemi aracılığıyla kolayca tamamlanamaz.
Operasyonların evrimi
İnsan çalıştırma ve bakım aşaması
BT endüstrisinin ilk günlerinde, altyapının otomasyonunu tamamlamak için sunucu işletimi ve bakımı çeşitli Ad Hoc komutları veya Shell komut dosyaları aracılığıyla gerçekleştiriliyordu. Bu yöntem basit ve tek seferlik görevler için uygundur, ancak karmaşık ve uzun vadeli projeler için, ikincisi Komut dosyası bakımı çok zahmetlidir.
Otomatik araç aşaması
Günümüzde, büyük İnternet şirketlerinin zaten binlerce sunucusu var.Bu kadar büyük bir sunucu ölçeği için, geçmişte orijinal manuel çalıştırma ve bakım yöntemleri açıkça güncel değil. Büyük ölçekli sunucuların otomatik ve hızlı çalışması ve bakımı bir zorunluluk haline geldi. Tartışılmayan konular.
Şu anda, Salt, Chef, Puppet ve Ansible gibi yapılandırma yönetimi araçları, işletim ve bakım endüstrisinde çok popüler araçlardır.Sunucuyu yönetmek için kendi dilbilgisi kurallarını tanımlarlar.Bu araçlar tarafından tanımlanan kod, Ad Hoc betik diline çok benzer, ancak kod gerektirirler. Yapı, tutarlılık ve açık parametre adlandırma ile çok sayıda sunucuyu uzaktan yönetebilirler ve ilk Ad hoc komut dosyalarıyla uyumludurlar.
DevOPS aşaması
Otomatik bakım için ilgili araçların sonsuz bir şekilde ortaya çıkmasıyla, bazı büyük şirketler bunu stratejik düzeye yükseltti ve kendi iş sistemlerini bir araya getirmek için çeşitli otomatik araçlar geliştirdiler.
Otomatik işletim ve bakım platformu ACM platformu yapımı
Suning, geleneksel işten İnternet'e dönüştü. İş hacmindeki artış, sunucunun standart taraması ve çekirdeğin toplu yükseltilmesiyle, Double 11 promosyonuna hazırlanırken, işletim ve bakım, çok sayıda sistem genişletme, yapılandırma, global değişken ayarlarına vb. Erişecektir. Yavaş yavaş normalleşti ve binlerce ana bilgisayarın işletimi ve bakımı artık bastion ana bilgisayar sistemi aracılığıyla kolayca tamamlanamıyor.
PAAS iş sistemleri, çeşitli özelleştirilebilir ve standartlaştırılmış sunucu yapılandırma yönetimi dağıtım arayüzleri gerektirmeye devam ettikçe. Sunucuları toplu halde yapılandırabilen ve yönetebilen evrensel bir platform geliştirmek acil hale geliyor.
Temel araçların seçimi
Şu anda piyasadaki en yaygın açık kaynak araçları Puppet / Chef / Ansible / Saltstack'tir. Github'daki popülerlik sıralaması aşağıdaki gibidir:
Gerçek gelişimin seçiminde, ilk olarak aşağıdaki iki nokta dikkate alınacaktır:
-
İlk olarak, dil seçimi (Puppet / Chef vs Ansible / Saltstack) Puppet ve Chef Ruby, Ansible ve Saltstack temel alınarak geliştirildi (ikincil geliştirme daha sonra yapılabilir), bu yüzden eski ve zayıf uyumlu Puppet and Chef'i bırakın
-
İkincisi, hız seçimi (Ansible vs Saltstack) Çalıştırma ve bakım yapılandırma yönetimi, daha hızlı ve daha kararlı vurgulanır Ansible, SSH protokolüne dayalı olarak verileri iletir ve Saltstack, verileri iletmek için mesaj kuyruğu zeroMQ kullanır.
Ansible ve Saltstack'in seçimleri arasında, bazı şirketlerin Saltstack'i terk etmesinin ana nedeni, Saltstack'in bir istemci kurması gerektiğidir; bu, Ansible'ın bir istemci kurmasına gerek kalmazken, belirli sayıda sunucu olduğunda zahmetli bir durumdur. Bununla birlikte, mevcut Ansible hala aşağıdaki zor problemlere sahiptir:
-
Ayarlanması zor: İşletme özellikleriyle ilgili gereksinimler çok ayrıktır (bazıları verimliliğe odaklanır, bazıları sürecin eksiksizliğine odaklanır ve bazıları yüksek kullanım kolaylığı gerektirir) ve giderek daha fazla talepkar taraflar vardır ve uygun bir evrensel açık arayüz yoktur Dinlendirici API sağlayın, işlev sunma sırası ciddi olacaktır.
-
Kötü performans: Sunucu düzeyinde K düzeyinde bir işlem yapmanız gerektiğinde, Ansible'ın yanıtı onlarca dakika kadar uzundur ve nispeten yüksek bir hata oranı vardır.
Öte yandan, SaltStack, hafif bir mesaj kuyruğu (ZeroMQ) ve Python üçüncü taraf modülleri birleştirilerek oluşturulmuştur. Yapılandırma yönetimi, uzaktan çalıştırma, izleme vb. İşlevlere sahiptir ve aşağıdaki belirgin avantajlara sahiptir:
-
Son derece hızlı
-
İyi uyumluluk
-
Belgeler ayrıntılıdır ve açık kaynak topluluğu Ansible kadar aktiftir
Hız testi
Tablodan Ansible ve SaltStack performans testlerinin Ansible ve SaltStack'in performansını komutları yürütme, dosyaları dağıtma, dosyaları okuma ve toplu komut dosyası yürütme gibi otomatik çalıştırma ve bakım senaryolarında test ettiği görülebilir.Zaman alan veriler Ansible'ın performansını göstermektedir. Yanıt hızı, SaltStack'ten yaklaşık 10 kat daha yavaştır.
Kapsamlı bir gösterim ve değerlendirmeden sonra, büyük ölçekli kümeler için en uygun olan SaltStack, nihayet tüm Suning sunucuları için temel yönetim aracı olarak seçildi.
Kullanımda stabilitenin korunması
Saltstack'in ilk sürümünün kararlılığı yüksek olmadığından, çeşitli sürümler arasında uyumluluk sorunları vardır.Sürüm yükseltildiğinde sürümün geriye dönük olarak uyumlu olmasını sağlamak için ekip, keşfedilen hataları birçok doğrulama ve testten sonra topluluğa bildirecektir. Sürekli iletişim ve müzakere, nihayet topluluk tarafından kabul edildi ve değişiklik önerilerimizi kabul etti. Şu anda ekip, temel platformun istikrarını etkin bir şekilde garanti eden Salt'ın yeni sürümünün doğrulanması, test edilmesi ve bakımına aktif olarak katılıyor.
Genel dış arayüz ve WEB platformu yapımı
Saltstack topluluğu bir WEB yönetim arayüzü sağlamadığından, tüm işlemler yalnızca komut satırı aracılığıyla gerçekleştirilebilir ve API çağrısı ayrıca kullanıcı adı ve parolayı harici sisteme ifşa eder ve Master'ın güvenliği garanti edilemez. Ve komut dosyalarının bakımı ve yükseltilmesi çok zahmetli.
Bu nedenle, altta yatan yönetim aracını seçtikten sonra, bir dizi ACM üst seviye platformu geliştirmek, harici hizmetler sağlamak için ortak bir arayüz paketlemek ve ana bilgisayar operasyonu ve bakım ekibi için görsel bir operasyon arayüzü sağlamak gerekir.
ACM, işletme ve bakım yöneticilerine görsel işletim ve bakım yönetimi gerçekleştirmeleri için bir dizi WEB sistemi sağlar. Sayfa komut dosyası aracı tanımlama, iş planlama, iş yürütme, komut yürütme, rapor analizi vb. İşlevlerini gerçekleştirir.
Harici sistem, Salt Minion Agent ile kurulan makinenin konfigürasyon yönetimini gerçekleştirmek için ACM tarafından açılan API arabirimi aracılığıyla temeldeki Salt'ı arayabilir.
Güvenlik tasarımı açısından, platform denetim, komut kara listesi, kanal yönetimi, Aracı yapılandırması, kullanıcı rolü yetki yönetimi sağlar ve yalnızca yetkili harici sistemlerin ACM'ye erişmesine izin verir.
Sistem mimarisinin evrimi
Mimari 1.0
Order Master + Syndic + Minion'un üç katmanlı mimari modeli ilk günlerde benimsendi. O zamanlar, Suning'deki OS sanal makineleri + fiziksel sunucuların toplam sayısı yaklaşık 10.000'di ve Salt'ın yerel mimarisi bunu zar zor destekleyebiliyordu.
Bununla birlikte, grubun dönüşümü devam ederken, çevrimiçi iş hacmi hızla arttı ve büyük promosyondan önce çevrimiçi olan sunucu sayısı da günde yaklaşık 1.000 oranında arttı. ACM'ye bağlı sistem sayısı da günde ikiden üçe çıktı. Toplam istek sayısı hızla düzinelerce sisteme yükseldi ve günde yaklaşık 10.000 yapılandırma görevi vardı Bu sırada, yavaş görev dönüşü gibi sistem sorunları kademeli olarak ortaya çıktı ve eşzamanlı bir görev yürütme, 5 saniyeden fazla arama süresi gerektiriyordu; Yerel mimari altında, eşzamanlı görevlerin sayısı büyük olduğunda, Order Master'ın sistem basıncı çok yüksektir ve görev başarısızlık oranı% 10'u aşar.
Ekip, müşterilerin sefaletiyle başa çıkmak için her gün çok zaman harcıyor ve iş tarafı sık sık şikayet ediyor. Artan iş hacmi nedeniyle, Salt-Minion varsayılan olarak grubun tek temel işletme ve bakım aracısıdır. Bizden başka hiç kimse otomatik yapılandırmayı üstlenemez. Yönetim çalışması. O zamandan beri ACM tüm sistemi yeniden tasarladı.
Mimari 2.0 iki katmanlı bölme
Tekrarlanan araştırma ve gösterilerden sonra, ACM, doğrudan Sipariş Yöneticisi rolü olarak hareket edecek şekilde dönüştürülebilir.Sunucuda yapılandırma görevlerini başlatırken, ACM, kurulum kaydı aracılığıyla hangi Ana Minion'un monte edildiğini doğrudan sorgulayabilir ve doğrudan gerekli Master'a çağrı başlatabilir. Birden fazla makine olması durumunda, sonuçlar daha sonra ACM aracılığıyla da toplanacaktır.
ACM'nin kendisi bir JBoss kümesi olduğundan, bu yalnızca tek bir Order Maser üzerindeki çok ağır yük sorununu çözmekle kalmaz, aynı zamanda orijinal beş saniye + yanıttan milisaniye yanıtına kadar, yerel mimarinin resmi sorununu çözen isteğin yanıt süresini büyük ölçüde hızlandırır. Harcanması gereken sendik bekleme süresi.
Mimari 2.1-Salt Master'ın yüksek kullanılabilirliği
Gerçek üretim ortamında, belirli bir Salt Master düşerse, yaklaşık 2K makine kontrolü kaybedecek ve manuel Ana kurtarma onlarca dakikaya kadar sürebilir, bu da bazı iş aramaları için kabul edilemez.
Bu nedenle, Kaptanın acilen yüksek kullanılabilirlikli bir dönüşüm gerçekleştirmesi gerekir ve dönüşüm sürecinde aşağıdaki sorunların çözülmesi gerekir:
Minion, Ustanın devrildiğini nasıl algılar ve hızlı bir geçiş yapar.
Minion, ana Ustanın devrede olduğunu algıladığında bekleme Ustasına nasıl geçilir.
Özellikle usta yeni bir minionu ilişkilendirdiğinde, efendi ve köle efendileri arasındaki tuz anahtarı replikasyonu problemi nasıl çözülür, yeni minyonun tuz anahtarının köle efendiyle nasıl senkronize edileceği.
plan 1
Saltstack'in yerel yüksek kullanılabilirlik çözümü Mutil-Master + Failover-Minion'u kullanıyor.
-
Mutil-Master : Saltstack, Minion'un birden fazla Ustaya bağlanabileceği özelliği sağlayan 0.16.0 sürümünden beri destekleniyor.
-
Failover-Minion : Minion, Ustanın uygunluğunu periyodik olarak kontrol eder, Ustanın müsait olmadığını anladığında, belirli bir zamanda yedek Usta'ya geçecektir.
Ana yapılandırma öğeleri aşağıdaki gibidir:
# multi-Master Usta: -10.27.135.188 -10.27.135.189 # Minion yük devretmeye ayarla Ana_tür: yük devretme # Master'ı saniye cinsinden algılama aralığı Master_alive_interval: < saniye >
Bu çözümün avantajı, SaltStack'in yerel yüksek kullanılabilirlik desteğine dayanması ve onu desteklemek için başka kombinasyon çözümlerine ihtiyaç duymamasıdır.Teorik olarak, Master'ın yüksek kullanılabilirliği elde edilebilir, ancak gerçek doğrulama ve testlerden sonra, bazı bariz eksiklikler vardır:
Minon, başlatıldığında rastgele bir Master'a bağlanacaktır.Eğer bağlı Master bu sırada kapalı olursa, Minion artık rastgele başka bir Master seçmeyecektir ve bu da bağlantı arızasına neden olacaktır.
Minion algılama aralığı, Master_alive_interval ayar süresine göre, Master'ın yanıt verip vermediğini görmek için Minion, mevcut Master'ın TCP bağlantısını aktif olarak kontrol edecektir. Algılama aralığı çok uzun ayarlanırsa, geçişin zamanlamasını etkileyebilir; algılama aralığı çok kısa ayarlanırsa, büyük ölçekli bir sunucu senaryosunda, kısa sürede çok fazla ağ isteği üretilecek ve bu da Ana ana bilgisayar ve ağ bant genişliği üzerinde büyük bir etkiye sahip olacaktır. , DDOS saldırısına eşdeğerdir.
Master'ın IP'sini değiştirmeniz veya yeni bir Master'ın IP'si eklemeniz gerekiyorsa, Master'ın altındaki tüm Minon'larda konfigürasyon değişiklikleri yapmanız gerekir.Daha korkunç olan şey ise Minion'un etkili olması için yeniden başlatılması gerekmesidir.
Tuz anahtarı senkronizasyonu bir çözüm sağlamaz.
Senaryo 2
Sürekli deneylerden sonra, Kaptanın, Keepalived tarafından sağlanan VIP aracılığıyla dışarıya Salt hizmetleri sağlayabildiği bulunmuştur.Genellikle, VIP, ana ana yöneticiye bağlıdır. Ana ana yönetici aşağı gittiğinde, VIP yedek ana yöneticiye sürüklenir ve ana ve yedek ana, Tuz anahtar dosyasını lsyncd aracılığıyla paylaşır.
Not: Kalıcı yazılım, esas olarak yüksek kullanılabilirlik işlevini VRRP protokolü aracılığıyla gerçekleştirir. VRRP, Virtual Router Redundancy Protocol'ün (Sanal Yönlendirici Yedeklilik Protokolü) kısaltmasıdır. VRRP'nin amacı, statik yönlendirmenin tek nokta arızası sorununu çözmektir. Bireysel düğümler çalışmadığında, tüm ağın kesintisiz çalışmasını sağlayabilir. .
Bu nedenle, Keepalived, bir yandan LVS'yi yapılandırma ve yönetme işlevine sahipken, aynı zamanda LVS altındaki düğümlerde sağlık kontrolleri yapma işlevine sahiptir, diğer yandan sistem ağ hizmetlerinin yüksek kullanılabilirliğini de gerçekleştirebilir. .
Gerçek operasyonda Minion, Master (VIP) ile kayıt işlemini aktif olarak başlatacak ve 5 dakikada bir Master ile TCP bağlantısını tespit edecektir.Bağlantı kesilirse, TCP el sıkışmasını yeniden başlatacak ve uzun bir TCP bağlantısı kuracaktır; Master düştüğünde, Keepalived Tespit edildikten sonra, VIP yedek Üstad'a geçecektir.Minion, en fazla 5 dakika sonra yedek Kaptanın VIP'sine bir TCP bağlantı isteği başlatacak ve Ustanın görevi başlatmasını bekleyerek uzun bağlantıyı yeniden askıya alacaktır.
Bu çözüm, yüksek kullanılabilirliği desteklemek için ek yazılımların yüklenmesini gerektirir .. Keepalived, Master'ın arıza süresini tespit eder ve lsyncd, Salt-key'in gerçek zamanlı senkronizasyonunu sağlar. Bunun avantajı, Seçenek 1'in birçok eksikliğinin önlenebilmesidir. Birincisi, Minion sonunun tanıdığı şey, sanal Master'ın IP adresidir, bu nedenle Master'ın temeldeki IP adresindeki değişiklik, Minion ucuna duyarsızdır.Minion'un konfigürasyonu değiştirmesi veya yeniden başlatması gerekmez; ikincisi, Keepalived'in canlı algılama mekanizması Bu ağ segmentindeki D sınıfı adresleri tespit edin ve benzersiz bir sanal yönlendirme kimliği ayarlayın. Algılama aralığı 5 saniye içinde kontrol edilir, böylece grup ağında herhangi bir etkisi olmayacaktır. Son olarak, lsyncd, bunu sağlamak için Tuz anahtarını senkronize eder Güvenlik ve birden fazla Master arasında tuz anahtarı senkronizasyonu sorunundan kaçının.
Bu noktada, yukarıdaki hibrit çözümler aracılığıyla, Salt Master'ın arıza süresi kendi kendini algılama ve otomatik geçişinin yüksek kullanılabilirlik çözümü başarıyla gerçekleştirilmiştir.Şu anda, Xingang ortamındaki sunucuların tümü, yüksek kullanılabilirlik mimarisine sahip Salt kümesi tarafından devralınmıştır.
sonuç olarak
Mevcut ACM, temel olarak grubun günlük ve büyük ölçekli toplu aramalarını tatmin etti:
-
Şu anda ACM, K-seviyesi sunucuların maksimum senkronizasyon çağrısını desteklemektedir.
-
ACM senkronizasyon basit görev çağrısının ortalama ek yük süresi yaklaşık 200 ms'dir.
-
Platformun ortalama günlük çağrı hacmi 500.000'e yakın
-
Başarı oranı% 99,99 isteme
Görünüm
Sistemin güvenilirliği garanti altına alındığı için sisteme erişim sayısı ve çağrı sayısı artacak, günlük ortalama milyonlarca ve on milyonlarca görev çağrısı ile nasıl başa çıkılacağı da gündemde olacak.
Gelecekteki AIOps, ACM'nin temel konfigürasyon hizmet platformunda daha yüksek gereksinimleri ortaya koyacaktır, çünkü komuta ve izleme sistemi karar verme için gerekli verileri topladığında, analiz ve karar verme aşamasında, ACM'nin eylemleri yürütmek ve kullanmak için bir araç olarak hareket etmesi gerekir. AI beyninin kararlarını uygulamak için otomatik komut dosyaları / komutlar.
Şu anda, Saltstack 150.000'den fazla sunucuyu yönetmiştir. Salt araması başarısız olduğunda, bunun nedeni makine arıza süresi, güvenlik duvarı kısıtlamaları, yedi katmanlı ağ arızası, yüksek sistem yükü, tam diskler vb. Olabilir. Bu nedenler Tuz çağrısının başarısızlığının bir sonucu olarak, Tuz arızası sorununa erken uyarı vermeyi ve sorunu akıllıca bulup çözmeyi umuyoruz.
Bununla birlikte, Salt'ın toplu olarak yürütülmesi sırasında görevlerin sonuçlarının kaybolma olasılığı vardır, çünkü tüm görevlerin geri dönüş sonuçları istemcinin aktif olarak sunucuya geri dönmesini gerektirir.Yığın görevler büyük olduğunda, birkaç makinenin geri dönüş sonuçları kaybolacaktır.
