Tupperware ile her ölçekteki kümelerin verimli ve güvenilir yönetimi
bugün Neredeyse tüm hizmetlerimizi çalıştıran milyonlarca sunucudaki konteynerleri düzenleyen küme yönetim sistemimiz Tupperware'i tanıttık. Tupperware'i ilk kez 2011'de kurduk ve o zamandan bu yana altyapımız büyüdü. bütüne . Bunca zaman Tupperware de durmadı ve bizimle birlikte gelişti. Durum bilgisi olan hizmetler için uygun destek, tüm veri merkezleri için tek bir kontrol paneli ve kapasiteyi hizmetler arasında gerçek zamanlı olarak dağıtma yeteneği de dahil olmak üzere Tupperware'in birinci sınıf küme yönetimini nasıl sağladığını size göstereceğiz. Altyapımız geliştikçe öğrendiğimiz dersleri de paylaşacağız.
Tupperware farklı görevleri yerine getirir. Uygulama geliştiricileri bunu uygulamaları sunmak ve yönetmek için kullanır. Uygulama kodunu ve bağımlılıkları bir görüntü halinde paketler ve bunu sunuculara konteynerler halinde teslim eder. Kapsayıcılar aynı sunucudaki uygulamalar arasında izolasyon sağlar, böylece geliştiriciler uygulama mantığıyla ilgilenir ve sunucu bulma veya güncellemeleri yönetme konusunda endişelenmelerine gerek kalmaz. Tupperware ayrıca sunucunun performansını da takip ediyor ve bir arıza bulması durumunda sorunlu sunucudan konteynerleri aktarıyor.
Kapasite planlama mühendisleri, sunucu kapasitesini bütçe ve kısıtlamalara göre ekiplere tahsis etmek için Tupperware'i kullanıyor. Ayrıca sunucu kullanımını iyileştirmek için de kullanıyorlar. Veri merkezi operatörleri, konteynerleri veri merkezleri arasında düzgün bir şekilde dağıtmak ve bakım sırasında konteynerleri durdurmak veya taşımak için Tupperware'e başvuruyor. Bu sayede sunucuların, ağların ve ekipmanların bakımı minimum düzeyde insan müdahalesi gerektirir.
Tupperware mimarisi
Tupperware PRN mimarisi veri merkezlerimizin bölgelerinden biridir. Bölge, yakınlarda bulunan çeşitli veri merkezi binalarından (PRN1 ve PRN2) oluşmaktadır. Tek bir bölgedeki tüm sunucuları yönetecek tek bir kontrol paneli yapmayı planlıyoruz.
Uygulama geliştiricileri hizmetleri Tupperware işleri şeklinde sunar. Bir iş birden fazla kapsayıcıdan oluşur ve bunların tümü genellikle aynı uygulama kodunu çalıştırır.
Tupperware, konteynerlerin tedarik edilmesinden ve yaşam döngülerinin yönetilmesinden sorumludur. Birkaç bileşenden oluşur:
- Tupperware ön ucu, kullanıcı arayüzü, CLI ve Tupperware ile etkileşimde bulunabileceğiniz diğer otomasyon araçları için API'ler sağlar. Tüm iç yapıyı Tupperware iş sahiplerinden gizliyorlar.
- Tupperware Scheduler, konteynerin ve iş yaşam döngüsünün yönetilmesinden sorumlu bir kontrol panelidir. Bölgesel zamanlayıcının bir bölgedeki sunucuları yönettiği ve küresel zamanlayıcının farklı bölgelerdeki sunucuları yönettiği bölgesel ve küresel düzeylerde dağıtılır. Zamanlayıcı parçalara bölünmüştür ve her parça bir dizi işi yönetir.
- Tupperware'in Zamanlayıcı Proxy'si dahili parçalamayı gizler ve Tupperware kullanıcıları için kullanışlı tek bir cam bölme sağlar.
- Tupperware ayırıcısı, kapları sunuculara atar. Zamanlayıcı, konteynerlerin durdurulmasını, başlatılmasını, güncellenmesini ve yük devretmesini yönetir. Şu anda tek bir ayırıcı, parçalara bölünmeden tüm bölgeyi yönetebiliyor. (Terminolojideki farklılığa dikkat edin. Örneğin, Tupperware'deki programlayıcı, Tupperware'deki kontrol paneline karşılık gelir. ve Tupperware ayırıcısına Kubernetes'te zamanlayıcı adı verilir.)
- Kaynak aracısı, sunucu ve hizmet olayları için doğruluk kaynağını saklar. Her veri merkezi için bir kaynak aracısı çalıştırıyoruz ve bu aracı, o veri merkezindeki sunucularla ilgili tüm bilgileri saklıyor. Kaynak komisyoncusu ve kapasite yönetim sistemi veya kaynak sağlama sistemi, hangi zamanlayıcı teslimatının hangi sunucuyu kontrol edeceğine dinamik olarak karar verir. Durum denetimi hizmeti, sunucuları izler ve durumlarıyla ilgili verileri kaynak aracısında saklar. Bir sunucunun sorunları varsa veya bakıma ihtiyacı varsa, kaynak komisyoncusu, ayırıcıya ve zamanlayıcıya konteynerleri durdurmasını veya başka sunuculara taşımasını söyler.
- Tupperware Agent, her sunucuda çalışan ve konteynerlerin sağlanmasını ve kaldırılmasını yöneten bir arka plan programıdır. Uygulamalar bir konteynerin içinde çalışır, bu da onlara daha fazla izolasyon ve tekrarlanabilirlik sağlar. Açık Görüntüler, btrfs, cgroupv2 ve systemd kullanılarak bireysel Tupperware kaplarının nasıl oluşturulduğunu zaten açıklamıştık.
Tupperware'in ayırt edici özellikleri
Tupperware birçok yönden Kubernetes gibi diğer küme yönetim sistemlerine benzer. ancak farklılıklar da var:
- Durum bilgisi olan hizmetler için yerleşik destek.
- Farklı veri merkezlerindeki sunucular için konteynerlerin amaca göre teslimini, kümelerin hizmet dışı bırakılmasını ve bakımını otomatikleştirmek için tek bir kontrol paneli.
- Yakınlaştırma için kontrol panelinin net bölümü.
- Esnek bilgi işlem, gücü hizmetler arasında gerçek zamanlı olarak dağıtmanıza olanak tanır.
Bu harika özellikleri, devasa bir küresel paylaşımlı sunucu filosundaki çeşitli durum bilgisi olmayan ve durum bilgisi olan uygulamaları desteklemek için geliştirdik.
Durum bilgisi olan hizmetler için yerleşik destek.
Tupperware, Facebook, Instagram, Messenger ve WhatsApp için kalıcı ürün verilerini depolayan çeşitli kritik durum bilgisi olan hizmetleri çalıştırır. Bunlar, anahtar/değer çiftlerinin büyük depoları olabilir (ör. ) ve veri havuzlarının izlenmesi (örneğin, и ). Durum bilgisi olan hizmetlerin bakımı kolay değildir çünkü sistemin, konteyner tedarikinin ağ kesintileri veya elektrik kesintileri dahil büyük ölçekli kesintilere dayanabilmesini sağlaması gerekir. Kapsayıcıları arıza etki alanları arasında dağıtmak gibi geleneksel teknikler durum bilgisi olmayan hizmetler için iyi çalışırken, durum bilgisi olan hizmetlerin ek desteğe ihtiyacı vardır.
Örneğin, bir sunucu arızası bir veritabanı kopyasını kullanılamaz duruma getirirse, 50 sunuculuk bir havuzdan 10 sunucudaki çekirdekleri güncelleyecek otomatik bakımı etkinleştirmeniz gerekir mi? Duruma göre. Bu 50 sunucudan birinde aynı veritabanının başka bir kopyası varsa, beklemek ve aynı anda 2 kopyayı kaybetmemek daha iyidir. Sistem bakımı ve performansı hakkında dinamik olarak kararlar verebilmek için, dahili veri çoğaltma ve her durum bilgisi olan hizmetin yerleştirme mantığı hakkında bilgiye ihtiyacımız var.
TaskControl arayüzü, durum bilgisi olan hizmetlerin veri kullanılabilirliğini etkileyen kararları etkilemesine olanak tanır. Zamanlayıcı, bu arayüzü kullanarak harici uygulamaları konteyner işlemleri (yeniden başlatma, güncelleme, geçiş, bakım) hakkında bilgilendirir. Durum bilgisi olan bir hizmet, Tupperware'e her işlemi gerçekleştirmenin ne zaman güvenli olduğunu bildiren bir denetleyici uygular ve bu işlemler geçici olarak değiştirilebilir veya geciktirilebilir. Yukarıdaki örnekte, veritabanı denetleyicisi Tupperware'e 49 sunucudan 50'unu güncellemesini ancak belirli bir sunucuyu (X) şimdilik yalnız bırakmasını söyleyebilir. Sonuç olarak, çekirdek güncelleme süresi geçerse ve veritabanı sorunlu kopyayı hala geri yükleyemezse Tupperware, X sunucusunu güncellemeye devam edecektir.
Tupperware'deki birçok durum bilgisi olan hizmet, TaskControl'ü doğrudan değil, Facebook'ta durum bilgisi olan hizmetler oluşturmak için ortak bir platform olan ShardManager aracılığıyla kullanır. Tupperware ile geliştiriciler, konteynerlerin veri merkezleri arasında tam olarak nasıl dağıtılması gerektiğine ilişkin niyetlerini belirtebilirler. ShardManager ile geliştiriciler, veri parçalarının kapsayıcılar arasında nasıl dağıtılması gerektiğine ilişkin niyetlerini belirtir. ShardManager, uygulamalarının veri yerleşimi ve çoğaltılmasının farkındadır ve doğrudan uygulama katılımı olmadan konteyner işlemlerini planlamak için TaskControl arayüzü aracılığıyla Tupperware ile iletişim kurar. Bu entegrasyon, durum bilgisi olan hizmetlerin yönetimini büyük ölçüde basitleştirir, ancak TaskControl daha fazlasını yapabilir. Örneğin, kapsamlı web katmanımız durum bilgisizdir ve kapsayıcılara yapılan güncellemelerin hızını dinamik olarak ayarlamak için TaskControl'ü kullanır. Sonunda kullanılabilirlikten ödün vermeden günlük.
Veri merkezlerindeki sunucuların yönetilmesi
Tupperware 2011 yılında ilk kez piyasaya sürüldüğünde, her sunucu kümesi ayrı bir zamanlayıcı tarafından yönetiliyordu. O zamanlar bir Facebook kümesi, bir ağ anahtarına bağlı bir grup sunucu rafından oluşuyordu ve veri merkezi birkaç kümeyi barındırıyordu. Zamanlayıcı yalnızca bir kümedeki sunucuları yönetebiliyordu, bu da işin birden fazla kümeye yayılamayacağı anlamına geliyordu. Altyapımız büyüdü, kümeleri giderek daha fazla sildik. Tupperware, işi hizmet dışı bırakılan kümeden diğer kümelere değişiklik yapmadan taşıyamayacağından, uygulama geliştiricileri ile veri merkezi operatörleri arasında çok fazla çaba ve dikkatli bir koordinasyon gerekiyordu. Bu süreç, hizmetten çıkarma prosedürleri nedeniyle sunucuların aylarca boşta kalması nedeniyle kaynakların israfına neden oldu.
Kümenin hizmet dışı bırakılması sorununu çözmek ve diğer bakım görevlerini koordine etmek için bir kaynak komisyoncusu oluşturduk. Kaynak aracısı, bir sunucuyla ilişkili tüm fiziksel bilgilerin izini sürer ve her sunucuyu hangi zamanlayıcının kontrol edeceğine dinamik olarak karar verir. Sunucuları zamanlayıcılara dinamik olarak bağlamak, zamanlayıcının farklı veri merkezlerindeki sunucuları yönetmesine olanak tanır. Bir Tupperware işi artık tek bir kümeyle sınırlı olmadığından Tupperware kullanıcıları, konteynerlerin hata etki alanlarına nasıl dağıtılması gerektiğini belirleyebilir. Örneğin, bir geliştirici belirli kullanılabilirlik bölgeleri belirtmeden niyetini beyan edebilir (örneğin: "işimi PRN bölgesindeki 2 hata etki alanında çalıştır"). Tupperware, küme veya hizmet kullanımdan kaldırılsa bile bu amacı gerçekleştirmek için uygun sunucuları kendisi bulacaktır.
Tüm küresel sistemi destekleyecek şekilde ölçeklenebilir
Geçmişte altyapımız bireysel ekipler için yüzlerce özel sunucu havuzuna bölünmüştü. Parçalanma ve standart eksikliği nedeniyle operasyonel maliyetlerimiz yüksekti ve boşta kalan sunucuların tekrar kullanılması zorlaştı. Geçen yılki konferansta sunduk altyapımızı büyük, tek bir sunucu parkında birleştirmeli. Ancak tek bir sunucu parkının da kendine has zorlukları vardır. Belirli gereksinimleri karşılaması gerekir:
- Ölçeklenebilirlik. Her bölgeye veri merkezleri ekledikçe altyapımız büyüdü. Sunucular daha küçük hale geldi ve enerji açısından daha verimli hale geldi; dolayısıyla her bölgede çok daha fazla sunucu var. Sonuç olarak, bölge başına tek bir zamanlayıcı, her bölgedeki yüzbinlerce sunucuda çalıştırılabilecek kapsayıcı sayısını işleyemez.
- Güvenilirlik. Zamanlayıcının ölçeği bu kadar büyütülebilse bile, zamanlayıcının geniş kapsamı, daha yüksek hata riski olduğu ve konteynerlerden oluşan bir bölgenin tamamının yönetilemez hale gelebileceği anlamına gelir.
- Hata toleransı. Büyük bir altyapı arızası durumunda (örneğin, zamanlayıcıyı çalıştıran sunucuların ağ arızası veya elektrik kesintisi nedeniyle arızalanması), olumsuz sonuçlar bölgedeki sunucuların yalnızca bir kısmını etkileyecektir.
- Kullanım kolaylığı. Bir bölge için birden fazla bağımsız zamanlayıcı çalıştırmanız gerekiyormuş gibi görünebilir. Ancak kolaylık açısından bakıldığında, bir bölgenin ortak havuzuna tek bir giriş noktası, kapasitenin ve işlerin yönetilmesini kolaylaştırır.
Büyük bir ortak havuzun bakımıyla ilgili sorunları çözmek için zamanlayıcıyı parçalara ayırdık. Her zamanlayıcı parçası bölgedeki kendi iş kümesini yönetir ve bu, zamanlayıcıyla ilişkili riski azaltır. Paylaşılan havuz büyüdükçe daha fazla zamanlayıcı parçası ekleyebiliriz. Tupperware kullanıcıları için parçalar ve zamanlayıcı proxy'leri tek bir kontrol paneli gibi görünür. Görevleri düzenleyen bir grup parçayla çalışmak zorunda değiller. Zamanlayıcı parçaları, daha önce kullandığımız küme zamanlayıcılardan temel olarak farklıdır; kontrol paneli, paylaşılan sunucu havuzunu ağ topolojisine göre statik olarak bölmeden bölümlendirilmiştir.
Esnek Bilgi İşlem ile Kullanım Verimliliğini Artırın
Altyapımız ne kadar büyük olursa, altyapı maliyetlerini optimize etmek ve yükü azaltmak için sunucularımızı verimli kullanmak o kadar önemlidir. Sunucu kullanımının verimliliğini artırmanın iki yolu vardır:
- Esnek bilgi işlem - Sessiz saatlerde çevrimiçi hizmetlerin ölçeğini azaltın ve makine öğrenimi ve MapReduce işleri gibi çevrimdışı iş yükleri için serbest bırakılan sunucuları kullanın.
- Aşırı Yükleme - Toplu iş yüklerinin düşük öncelikte çalışması için çevrimiçi hizmetleri ve toplu iş yüklerini aynı sunuculara yerleştirin.
Veri merkezlerimizdeki darboğaz . Bu nedenle, birlikte daha fazla işlem gücü sağlayan, enerji tasarrufu sağlayan küçük sunucuları tercih ediyoruz. Maalesef, CPU'su ve belleği az olan küçük sunucularda aşırı yükleme daha az etkilidir. Elbette, çok az işlemci kaynağı ve bellek tüketen, enerji açısından verimli küçük bir sunucuya küçük hizmetlerden oluşan birkaç konteyner yerleştirebiliriz, ancak bu durumda büyük hizmetlerin performansı düşük olacaktır. Bu nedenle, büyük hizmetlerimizin geliştiricilerine, sunucuların tamamını kullanacak şekilde bunları optimize etmelerini tavsiye ediyoruz.
Temel olarak elastik bilgi işlem kullanarak kullanım verimliliğini artırıyoruz. Haber Kaynağı, Mesajlaşma özelliği ve ön uç web katmanı gibi önemli hizmetlerimizin çoğu günün saatine göre değişiklik gösterir. Sessiz saatlerde çevrimiçi hizmetlerin ölçeğini kasıtlı olarak azaltıyoruz ve makine öğrenimi ve MapReduce işleri gibi çevrimdışı iş yükleri için serbest bırakılan sunucuları kullanıyoruz.
Deneyimlerimizden, sunucuların tamamını elastik kapasite birimleri olarak sağlamanın en iyisi olduğunu biliyoruz; çünkü büyük hizmetler, elastik kapasitenin hem ana bağışçıları hem de ana tüketicileridir ve sunucuların tamamını kullanacak şekilde optimize edilmiştir. Sunucu, sessiz saatlerde çevrimiçi hizmetten çıkarıldığında, kaynak aracısı, üzerinde çevrimdışı iş yükleri çalıştırması için sunucuyu zamanlayıcıya kiralar. Çevrimiçi hizmetin yoğun bir yüke maruz kalması durumunda, kaynak komisyoncusu ödünç alınan sunucuyu hızlı bir şekilde geri çağırır ve zamanlayıcıyla birlikte onu çevrimiçi hizmete geri gönderir.
Alınan dersler ve geleceğe yönelik planlar
Son 8 yıldır Facebook'un hızlı büyümesine ayak uydurmak için Tupperware'i geliştiriyoruz. Öğrendiklerimizi paylaşıyoruz ve başkalarının hızla büyüyen altyapıları yönetmesine yardımcı olacağını umuyoruz:
- Kontrol paneli ile yönettiği sunucular arasında esnek bir bağlantı kurun. Bu esneklik, kontrol panelinin farklı veri merkezlerindeki sunucuları yönetmesine olanak tanır, kümelerin hizmet dışı bırakılmasının ve bakımının otomatikleştirilmesine yardımcı olur ve elastik bilgi işlem kullanarak dinamik kapasite tahsisine olanak tanır.
- Bölgede tek bir kontrol paneli ile görevlerle çalışmak daha kolay hale gelir ve geniş bir paylaşımlı sunucu filosunu yönetmek daha kolay hale gelir. Ölçek veya hata toleransı nedenleriyle iç yapısı ayrılmış olsa bile kontrol panelinin tek bir giriş noktasını koruduğunu unutmayın.
- Bir eklenti modeli kullanarak kontrol paneli, yaklaşan konteyner operasyonları hakkında harici uygulamaları bilgilendirebilir. Ayrıca durum bilgisi olan hizmetler, konteyner yönetimini özelleştirmek için eklenti arayüzünü kullanabilir. Bu eklenti modeli ile kontrol paneli, birçok farklı durum bilgisi olan hizmete verimli bir şekilde hizmet verirken basitlik sağlar.
- Toplu işler, makine öğrenimi ve diğer acil olmayan hizmetler için sunucuların tamamını bağışçı hizmetlerinden aldığımız elastik bilişimin, küçük, enerji açısından verimli sunucuların verimliliğini artırmanın en iyi yolu olduğuna inanıyoruz.
Uygulamaya yeni başlıyoruz . Şu anda sunucularımızın yaklaşık %20'si ortak bir havuzdadır. %100'e ulaşmak için, paylaşılan bir depolama havuzunun bakımı, bakımın otomatikleştirilmesi, kiracılar arası gereksinimlerin yönetilmesi, sunucu kullanımının iyileştirilmesi ve makine öğrenimi iş yüklerine yönelik desteğin geliştirilmesi dahil olmak üzere birçok sorunun ele alınması gerekir. Bu zorlukların üstesinden gelmek ve başarılarımızı paylaşmak için sabırsızlanıyoruz.
Kaynak: habr.com