Tek bulut - Odnoklassniki'de veri merkezi düzeyinde işletim sistemi

Aloha millet! Adım Oleg Anastasyev, Odnoklassniki'de Platform ekibinde çalışıyorum. Ve Odnoklassniki'de benim dışımda çalışan birçok donanım var. 500 binin üzerinde sunucuya sahip 8'e yakın raflı dört veri merkezimiz var. Belirli bir noktada, yeni bir yönetim sisteminin uygulamaya konulmasının, ekipmanı daha verimli bir şekilde yüklememize, erişim yönetimini kolaylaştırmamıza, bilgi işlem kaynaklarının (yeniden) dağıtımını otomatikleştirmemize, yeni hizmetlerin başlatılmasını hızlandırmamıza ve yanıtları hızlandırmamıza olanak sağlayacağını fark ettik. büyük ölçekli kazalara

Ne oldu?

Benim ve bir sürü donanımın yanı sıra bu donanımla çalışan insanlar da var: Doğrudan veri merkezlerinde bulunan mühendisler; ağ yazılımı kuran ağ kullanıcıları; altyapı esnekliği sağlayan yöneticiler veya SRE'ler; ve geliştirme ekiplerinin her biri portalın işlevlerinin bir kısmından sorumludur. Oluşturdukları yazılım şöyle çalışır:

Kullanıcı talepleri hem ana portalın ön panellerinden alınır www.ok.ruve diğerlerinde, örneğin müzik API cephesinde. İş mantığını işlemek için, isteği işlerken gerekli özel mikro hizmetleri - tek grafik (sosyal bağlantı grafiği), kullanıcı önbelleği (kullanıcı profillerinin önbelleği) vb. çağıran uygulama sunucusunu çağırırlar.

Bu hizmetlerin her biri birçok makineye konuşlandırılmıştır ve her birinde modüllerin işleyişinden, işleyişinden ve teknolojik gelişimden sorumlu sorumlu geliştiriciler bulunur. Tüm bu hizmetler donanım sunucularında çalışır ve yakın zamana kadar sunucu başına tam olarak bir görev başlattık, yani belirli bir görev için uzmanlaşmıştı.

Nedenmiş? Bu yaklaşımın birçok avantajı vardı:

• Rahatlamak kitle yönetimi. Diyelim ki bir görev bazı kitaplıklar, bazı ayarlar gerektiriyor. Daha sonra sunucu tam olarak belirli bir gruba atanır, bu grup için cfengine politikası tanımlanır (veya zaten açıklanmıştır) ve bu yapılandırma, bu gruptaki tüm sunuculara merkezi olarak ve otomatik olarak dağıtılır.
• Basitleştirilmiş tanılama. Diyelim ki merkezi işlemci üzerindeki artan yüke bakıyorsunuz ve bu yükün yalnızca bu donanım işlemcisi üzerinde çalışan görev tarafından oluşturulabileceğini fark ediyorsunuz. Suçlayacak birini arama süreci çok çabuk sona erer.
• Basitleştirilmiş izleme. Sunucuda bir sorun varsa monitör bunu bildirir ve siz tam olarak kimin suçlanacağını bilirsiniz.

Birkaç kopyadan oluşan bir hizmete, her biri için bir tane olmak üzere birkaç sunucu tahsis edilir. Daha sonra hizmet için bilgi işlem kaynağı çok basit bir şekilde tahsis edilir: hizmetin sahip olduğu sunucu sayısı, tüketebileceği maksimum kaynak miktarı. Buradaki “Kolay” kullanımın kolay olduğu anlamına gelmiyor, kaynak tahsisinin manuel olarak yapılması anlamındadır.

Bu yaklaşım aynı zamanda şunları yapmamıza da olanak sağladı: özel demir konfigürasyonları Bu sunucuda çalışan bir görev için. Görev büyük miktarda veri depoluyorsa, 4 diskli kasaya sahip 38U sunucu kullanırız. Görev tamamen hesaplamaya dayalıysa, daha ucuz bir 1U sunucu satın alabiliriz. Bu hesaplama açısından verimlidir. Diğer şeylerin yanı sıra, bu yaklaşım, dost canlısı bir sosyal ağla karşılaştırılabilecek bir yüke sahip makinelerin dört kat daha azını kullanmamıza olanak tanıyor.

En pahalı şeyin sunucular olduğu varsayımından hareket edersek, bilgi işlem kaynaklarının kullanımındaki bu verimlilik aynı zamanda ekonomik verimliliği de sağlamalıdır. Uzun bir süre boyunca donanım en pahalı olanıydı ve donanım güvenilirliği gereksinimlerini azaltmak için hata toleransı algoritmaları geliştirerek donanım fiyatını düşürmek için çok çaba harcadık. Ve bugün artık sunucu fiyatının belirleyici olmaktan çıktığı aşamaya geldik. En son egzotikleri dikkate almazsanız, raftaki sunucuların özel yapılandırması önemli değildir. Şimdi başka bir sorunumuz var - sunucunun veri merkezinde kapladığı alanın, yani raftaki alanın fiyatı.

Durumun böyle olduğunu anlayınca rafları ne kadar verimli kullandığımızı hesaplamaya karar verdik.
En güçlü sunucunun fiyatını ekonomik olarak makul olanlardan aldık, bu tür sunuculardan kaç tanesini raflara yerleştirebileceğimizi, eski model olan “bir sunucu = bir görev” esasına göre bu sunucularda kaç görev çalıştıracağımızı ve ne kadarını hesaplayacağımızı hesapladık. görevler ekipmanı kullanabilir. Sayıp gözyaşı döktüler. Raf kullanımındaki verimliliğimizin %11 civarında olduğu ortaya çıktı. Sonuç açıktır: Veri merkezlerinin kullanımının verimliliğini artırmamız gerekiyor. Görünüşe göre çözüm açık: tek bir sunucuda aynı anda birkaç görevi çalıştırmanız gerekiyor. Ancak zorlukların başladığı yer burasıdır.

Toplu yapılandırma çok daha karmaşık hale geliyor; herhangi bir grubu bir sunucuya atamak artık imkansız. Sonuçta, artık tek bir sunucuda farklı komutlardan oluşan birkaç görev başlatılabilir. Ayrıca, yapılandırma farklı uygulamalar için çakışabilir. Teşhis de daha karmaşık hale gelir: Bir sunucuda artan CPU veya disk tüketimi görürseniz, hangi görevin soruna neden olduğunu bilemezsiniz.

Ancak asıl önemli olan, aynı makinede çalışan görevler arasında hiçbir izolasyonun olmamasıdır. Burada, örneğin, bir sunucu görevinin, aynı sunucuda başka bir hesaplama uygulamasının başlatılmasından önceki ve sonraki ortalama yanıt süresinin grafiği yer almaktadır; hiçbir şekilde ilkiyle ilişkili değildir - ana görevin yanıt süresi önemli ölçüde artmıştır.

Açıkçası, görevleri konteynerlerde veya sanal makinelerde çalıştırmanız gerekiyor. Görevlerimizin neredeyse tamamı tek bir işletim sistemi (Linux) altında çalıştığından veya ona uyarlandığından, çok sayıda farklı işletim sistemini desteklememize gerek yok. Buna göre sanallaştırmaya gerek yoktur; ek yük nedeniyle konteynerizasyona göre daha az verimli olacaktır.

Görevleri doğrudan sunucularda çalıştırmak için kapsayıcıların bir uygulaması olarak Docker iyi bir adaydır: dosya sistemi görüntüleri, çakışan yapılandırmalarla ilgili sorunları iyi bir şekilde çözer. Görüntülerin birkaç katmandan oluşabilmesi, ortak parçaları ayrı temel katmanlara ayırarak bunları altyapıya yerleştirmek için gereken veri miktarını önemli ölçüde azaltmamıza olanak tanır. Daha sonra temel (ve en hacimli) katmanlar, tüm altyapı boyunca oldukça hızlı bir şekilde önbelleğe alınacak ve birçok farklı uygulama ve sürüm türünü sunmak için yalnızca küçük katmanların aktarılması gerekecektir.

Ayrıca, Docker'daki hazır bir kayıt defteri ve görüntü etiketleme, bize sürüm oluşturma ve kodu üretime teslim etme için hazır temel öğeler sağlar.

Docker, diğer benzer teknolojiler gibi, bize kutunun dışında bir düzeyde konteyner izolasyonu sağlıyor. Örneğin, bellek izolasyonu - her konteynere, makine belleğinin kullanımı konusunda, bunun ötesinde tüketmeyeceği bir sınır verilir. Kapları CPU kullanımına göre de izole edebilirsiniz. Ancak bizim için standart yalıtım yeterli değildi. Ancak bunun hakkında daha fazlası aşağıda.

Konteynerleri doğrudan sunucularda çalıştırmak sorunun yalnızca bir kısmıdır. Diğer kısım ise konteynerlerin sunucularda barındırılmasıyla ilgilidir. Hangi sunucuya hangi konteynerin yerleştirilebileceğini anlamalısınız. Bu o kadar kolay bir iş değil çünkü konteynerlerin sunuculara hızlarını düşürmeden mümkün olduğunca yoğun bir şekilde yerleştirilmesi gerekiyor. Bu tür bir yerleştirme, hata toleransı açısından da zor olabilir. Genellikle aynı hizmetin kopyalarını farklı raflara, hatta veri merkezinin farklı odalarına yerleştirmek isteriz, böylece bir raf veya oda arızalanırsa tüm hizmet kopyalarını hemen kaybetmeyiz.

8 bin sunucunuz ve 8-16 bin konteyneriniz varken konteynerleri manuel olarak dağıtmak bir seçenek değil.

Ayrıca geliştiricilere, bir yöneticinin yardımı olmadan hizmetlerini üretimde kendileri barındırabilmeleri için kaynak tahsisinde daha fazla bağımsızlık vermek istedik. Aynı zamanda bazı küçük hizmetlerin veri merkezlerimizin tüm kaynaklarını tüketmemesi için kontrolü sürdürmek istedik.

Açıkçası bunu otomatik olarak yapacak bir kontrol katmanına ihtiyacımız var.

Böylece tüm mimarların hayran olduğu basit ve anlaşılır bir resme geldik: üç kare.

tek bulut yöneticileri, bulut orkestrasyonundan sorumlu bir yük devretme kümesidir. Geliştirici, hizmeti barındırmak için gerekli tüm bilgileri içeren ana bilgisayara bir bildirim gönderir. Buna dayanarak, usta seçilen kölelere (konteynerleri çalıştırmak için tasarlanmış makineler) komutlar verir. Minyonlar, komutu alan, komutlarını Docker'a veren aracımıza sahipler ve Docker, ilgili konteyneri başlatacak şekilde linux çekirdeğini yapılandırıyor. Ajan, komutları yürütmenin yanı sıra, hem minyon makinesinin hem de üzerinde çalışan konteynerlerin durumundaki değişiklikler hakkında sürekli olarak ustaya rapor verir.

Kaynak Tahsisi

Şimdi birçok köle için daha karmaşık kaynak tahsisi sorununa bakalım.

Tek buluttaki bir bilgi işlem kaynağı:

• Belirli bir görev tarafından tüketilen işlemci gücü miktarı.
• Görev için kullanılabilir bellek miktarı.
• Ağ trafiği. Minyonların her birinin sınırlı bant genişliğine sahip belirli bir ağ arayüzü vardır, bu nedenle ağ üzerinden aktardıkları veri miktarını hesaba katmadan görevleri dağıtmak imkansızdır.
• Diskler. Açıkçası, bu görevler için alana ek olarak disk türünü de tahsis ediyoruz: HDD veya SSD. Diskler saniyede sınırlı sayıda isteğe (IOPS) hizmet verebilir. Bu nedenle, tek bir diskin işleyebileceğinden daha fazla IOPS üreten görevler için ayrıca "iş milleri", yani özel olarak görev için ayrılması gereken disk aygıtları da tahsis ederiz.

Daha sonra bazı hizmetler için, örneğin kullanıcı önbelleği için, tüketilen kaynakları şu şekilde kaydedebiliriz: 400 işlemci çekirdeği, 2,5 TB bellek, her iki yönde 50 Gbit/s trafik, 6 iş milinde bulunan 100 TB HDD alanı . Veya bunun gibi daha tanıdık bir biçimde:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

Kullanıcı önbellek hizmeti kaynakları, üretim altyapısındaki mevcut kaynakların yalnızca bir kısmını tüketir. Bu nedenle, bir operatör hatası nedeniyle veya olmasın, kullanıcı önbelleğinin aniden tahsis edilenden daha fazla kaynak tüketmediğinden emin olmak istiyorum. Yani kaynakları sınırlamamız gerekiyor. Peki kotayı neye bağlayabiliriz?

Bileşenlerin etkileşimini gösteren büyük ölçüde basitleştirilmiş diyagramımıza dönelim ve onu daha fazla ayrıntıyla yeniden çizelim - şöyle:

Ne göze çarpar:

• Web ön ucu ve müzik, aynı uygulama sunucusunun yalıtılmış kümelerini kullanır.
• Bu kümelerin ait olduğu mantıksal katmanları ayırt edebiliriz: ön kısımlar, önbellekler, veri depolama ve yönetim katmanı.
• Ön uç heterojendir; farklı işlevsel alt sistemlerden oluşur.
• Önbellekler, verilerini önbelleğe aldıkları alt sisteme de dağılmış olabilir.

Resmi tekrar çizelim:

Bah! Evet, bir hiyerarşi görüyoruz! Bu, kaynakları daha büyük parçalara dağıtabileceğiniz anlamına gelir: sorumlu bir geliştiriciyi bu hiyerarşinin işlevsel alt sisteme karşılık gelen bir düğümüne atayın (resimdeki "müzik" gibi) ve hiyerarşinin aynı düzeyine bir kota ekleyin. Bu hiyerarşi aynı zamanda yönetim kolaylığı için hizmetleri daha esnek bir şekilde organize etmemize de olanak tanır. Örneğin, bu çok büyük bir sunucu grubu olduğu için tüm web'i, resimde grup1, grup2 olarak gösterilen birkaç küçük gruba ayırıyoruz.

Fazladan çizgileri kaldırarak resmimizin her düğümünü daha düz bir biçimde yazabiliriz: grup1.web.front, api.music.front, kullanıcı-cache.cache.

“Hiyerarşik kuyruk” kavramına bu şekilde ulaşıyoruz. "group1.web.front" gibi bir adı var. Kaynaklar ve kullanıcı hakları için bir kota atanır. DevOps'tan gelen kişiye kuyruğa hizmet gönderme haklarını vereceğiz ve böyle bir çalışan kuyrukta bir şeyler başlatabilir ve OpsDev'den gelen kişi yönetici haklarına sahip olacak ve artık kuyruğu yönetebilir, oraya kişileri atayabilir, bu kişilere haklar vb. verin. Bu kuyrukta çalışan hizmetler kuyruğun kotası dahilinde çalışacaktır. Kuyruğun bilgi işlem kotası tüm hizmetleri aynı anda yürütmek için yeterli değilse, bunlar sırayla yürütülecek ve böylece kuyruğun kendisi oluşturulacaktır.

Hizmetlere daha yakından bakalım. Bir hizmetin her zaman kuyruğun adını içeren tam nitelikli bir adı vardır. Daha sonra ön web hizmetinin adı olacaktır. ok-web.group1.web.front. Ve eriştiği uygulama sunucusu hizmeti çağrılacak ok-app.group1.web.front. Her hizmetin, belirli makinelere yerleştirilmesi için gerekli tüm bilgileri belirten bir bildirimi vardır: bu görevin ne kadar kaynak tükettiği, hangi yapılandırmanın gerekli olduğu, kaç kopya olması gerektiği, bu hizmetin arızalarını gidermeye yönelik özellikler. Hizmet doğrudan makinelere yerleştirildikten sonra örnekleri görünür. Ayrıca örnek numarası ve hizmet adı olarak da açıkça adlandırılırlar: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Bu çok kullanışlıdır: Yalnızca çalışan konteynerin adına bakarak hemen çok şey öğrenebiliriz.

Şimdi bu örneklerin gerçekte ne yaptığına daha yakından bakalım: görevler.

Görev Yalıtım Sınıfları

OK'deki (ve muhtemelen her yerde) tüm görevler gruplara ayrılabilir:

• Kısa Gecikmeli Görevler - prod. Bu tür görev ve hizmetler için yanıt gecikmesi (gecikme), isteklerin her birinin sistem tarafından ne kadar hızlı işleneceği çok önemlidir. Görev örnekleri: web cepheleri, önbellekler, uygulama sunucuları, OLTP depolama vb.
• Hesaplama sorunları - toplu. Burada her bir özel isteğin işlem hızı önemli değildir. Onlar için bu görevin belirli (uzun) bir zaman diliminde (verim) kaç hesaplama yapacağı önemlidir. Bunlar MapReduce, Hadoop, makine öğrenimi ve istatistiklerin herhangi bir görevi olacaktır.
• Arka plan görevleri - boşta. Bu tür görevler için ne gecikme ne de verim çok önemlidir. Buna çeşitli testler, geçişler, yeniden hesaplamalar ve verilerin bir formattan diğerine dönüştürülmesi dahildir. Bir yandan hesaplanmış olanlara benziyorlar, diğer yandan ne kadar çabuk tamamlandıkları bizim için pek önemli değil.

Bu tür görevlerin, örneğin merkezi işlemci gibi kaynakları nasıl tükettiğini görelim.

Kısa gecikmeli görevler. Böyle bir görevin CPU tüketim modeli şuna benzer:

Kullanıcıdan işlenmek üzere bir istek alınır, görev mevcut tüm CPU çekirdeklerini kullanmaya başlar, onu işler, bir yanıt verir, bir sonraki isteği bekler ve durur. Bir sonraki istek geldi - yine orada olan her şeyi seçtik, hesapladık ve bir sonrakini bekliyoruz.

Böyle bir görev için minimum gecikmeyi garanti etmek amacıyla, tükettiği maksimum kaynağı almalı ve gerekli sayıda çekirdeği minyonda (görevi yürütecek makine) ayırmalıyız. O zaman sorunumuzun rezervasyon formülü şu şekilde olacaktır:

alloc: cpu = 4 (max)

ve eğer 16 çekirdekli bir minion makinemiz varsa, o zaman bu tür tam dört görevi ona yerleştirebiliriz. Bu tür görevlerin ortalama işlemci tüketiminin genellikle çok düşük olduğunu özellikle not ediyoruz; bu açıktır, çünkü görev zamanın önemli bir bölümünde bir istek bekler ve hiçbir şey yapmaz.

Hesaplama görevleri. Desenleri biraz farklı olacak:

Bu tür görevler için ortalama CPU kaynak tüketimi oldukça yüksektir. Çoğu zaman bir hesaplama görevinin belirli bir sürede tamamlanmasını isteriz, dolayısıyla tüm hesaplamanın kabul edilebilir bir sürede tamamlanması için ihtiyaç duyduğu minimum işlemci sayısını ayırmamız gerekir. Rezervasyon formülü şöyle görünecek:

alloc: cpu = [1,*)

"Lütfen onu en az bir serbest çekirdeğin bulunduğu bir minyonun üzerine yerleştirin, sonra ne kadar varsa her şeyi yutacaktır."

Burada kullanım verimliliği zaten kısa gecikmeli görevlerden çok daha iyi. Ancak her iki görev türünü tek bir minion makinesinde birleştirirseniz ve kaynaklarını hareket halindeyken dağıtırsanız kazanç çok daha büyük olacaktır. Kısa gecikmeli bir görev bir işlemci gerektirdiğinde, onu hemen alır ve kaynaklara artık ihtiyaç duyulmadığında bunlar hesaplamalı göreve aktarılır, yani şöyle bir şey:

Ama nasıl yapmalı?

Öncelikle prod'a ve tahsisine bakalım: cpu = 4. Dört çekirdek ayırmamız gerekiyor. Docker çalıştırmasında bu iki şekilde yapılabilir:

• Seçeneği kullanma --cpuset=1-4, yani makinedeki dört belirli çekirdeği göreve ayırın.
• Kullanmak --cpuquota=400_000 --cpuperiod=100_000, işlemci süresi için bir kota atayın, yani her 100 ms gerçek zamanlı görevin 400 ms'den fazla işlemci süresi tüketmediğini belirtin. Aynı dört çekirdek elde edilir.

Peki bu yöntemlerden hangisi uygundur?

cpuset oldukça çekici görünüyor. Görevin dört ayrılmış çekirdeği vardır; bu, işlemci önbelleklerinin mümkün olduğu kadar verimli çalışacağı anlamına gelir. Bunun bir dezavantajı da var: hesaplamaları işletim sistemi yerine makinenin yüksüz çekirdeklerine dağıtma görevini üstlenmemiz gerekir ve bu oldukça önemsiz bir görevdir, özellikle de toplu görevleri böyle bir yere yerleştirmeye çalışırsak. makine. Testler, kotalı seçeneğin buraya daha uygun olduğunu gösterdi: Bu şekilde işletim sistemi, o anda görevi gerçekleştirmek için çekirdeği seçme konusunda daha fazla özgürlüğe sahip olur ve işlemci zamanı daha verimli bir şekilde dağıtılır.

Minimum çekirdek sayısına göre Docker'da nasıl rezervasyon yapılacağını bulalım. Toplu görevler için kota artık geçerli değildir, çünkü maksimumu sınırlamaya gerek yoktur, sadece minimumu garanti etmek yeterlidir. Ve burada seçenek iyi uyuyor docker run --cpushares.

Bir partinin en az bir çekirdek için garanti gerektirmesi durumunda bunu belirtmemiz konusunda anlaştık. --cpushares=1024ve en az iki çekirdek varsa, o zaman şunu belirtiriz: --cpushares=2048. Cpu paylaşımları, yeterli süre olduğu sürece işlemci süresinin dağıtımına hiçbir şekilde müdahale etmez. Bu nedenle, prod şu anda dört çekirdeğinin tamamını kullanmıyorsa toplu görevleri sınırlayan hiçbir şey yoktur ve ek işlemci süresi kullanabilirler. Ancak işlemci sıkıntısının olduğu bir durumda, eğer prod dört çekirdeğini de tüketmiş ve kotasına ulaşmışsa, kalan işlemci süresi cpushare'lara orantılı olarak bölünecektir, yani üç boş çekirdek olması durumunda, biri 1024 cpushare'lik bir göreve verilecek, geri kalan ikisi ise 2048 cpushare'lik bir göreve verilecek.

Ancak kota ve paylaşımları kullanmak yeterli değildir. İşlemci zamanı tahsis edilirken, kısa gecikmeli bir görevin toplu göreve göre öncelik aldığından emin olmamız gerekir. Böyle bir önceliklendirme olmadığında, toplu görev, ürünün ihtiyaç duyduğu anda işlemcinin tüm zamanını alacaktır. Docker çalıştırmasında kapsayıcı önceliklendirme seçeneği yoktur ancak Linux CPU zamanlayıcı politikaları kullanışlıdır. Onlar hakkında ayrıntılı olarak okuyabilirsiniz buradaBu yazı çerçevesinde kısaca bunların üzerinden geçeceğiz:

• SCHED_OTHER
  Varsayılan olarak Linux makinesindeki tüm normal kullanıcı işlemleri alınır.
• SCHED_BATCH
  Kaynak yoğun süreçler için tasarlanmıştır. Bir işlemciye bir görev yerleştirirken, sözde etkinleştirme cezası uygulanır: böyle bir görevin, şu anda SCHED_OTHER ile bir görev tarafından kullanılıyorsa, işlemci kaynaklarını alma olasılığı daha düşüktür.
• SCHED_IDLE
  Nice -19'dan bile daha düşük, çok düşük önceliğe sahip bir arka plan işlemi. Açık kaynak kütüphanemizi kullanıyoruz bir-nio, konteyneri çağırarak başlatırken gerekli politikayı ayarlamak için

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Ancak Java'da programlama yapmasanız bile aynı şey chrt komutu kullanılarak da yapılabilir:

chrt -i 0 $pid

Netlik sağlamak için tüm izolasyon düzeylerimizi tek bir tabloda özetleyelim:

Yalıtım sınıfı
Tahsis örneği
Docker çalıştırma seçenekleri
sched_setscheduler chrt*

Prod
işlemci = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Yığın
İşlemci = [1, *)
--cpushares=1024
SCHED_BATCH

boş
İşlemci= [2, *)
--cpushares=2048
SCHED_IDLE

*Chrt'yi bir konteynerin içinden yapıyorsanız sys_nice özelliğine ihtiyacınız olabilir, çünkü Docker varsayılan olarak konteyneri başlatırken bu yeteneği kaldırır.

Ancak görevler yalnızca işlemciyi değil aynı zamanda trafiği de tüketir; bu da ağ görevinin gecikmesini işlemci kaynaklarının yanlış tahsisinden daha fazla etkiler. Bu nedenle doğal olarak trafikte tam olarak aynı görüntüyü elde etmek istiyoruz. Yani, bir üretim görevi ağa bazı paketler gönderdiğinde maksimum hızı sınırlandırırız (formül tahsis: lan=[*,500mbps) ), bunu hangi ürünle yapabilir? Toplu iş için yalnızca minimum verimi garanti ediyoruz, ancak maksimumu sınırlamıyoruz (formül tahsis: lan=[10Mbps,*) ) Bu durumda ürün trafiğinin toplu görevlere göre öncelik alması gerekir.
Burada Docker'da kullanabileceğimiz herhangi bir ilkel öğe yok. Ama yardımımıza geliyor Linux Trafik Kontrolü. Disiplin yardımıyla istenilen sonuca ulaşabildik Hiyerarşik Adil Servis Eğrisi. Onun yardımıyla iki trafik sınıfını ayırt ediyoruz: yüksek öncelikli üretim ve düşük öncelikli toplu iş/boşta. Sonuç olarak, giden trafiğin yapılandırması şu şekildedir:

burada 1:0, hsfc disiplininin “kök qdisc'idir”; 1:1 - tüm kapsayıcıların alt sınıflarının yerleştirildiği, toplam bant genişliği sınırı 8 Gbit/s olan hsfc alt sınıfı; 1:2 - hsfc alt sınıfı, aşağıda tartışılan "dinamik" limitle tüm toplu ve boşta görevlerde ortaktır. Geriye kalan hsfc alt sınıfları, bildirimlerine karşılık gelen sınırlara (450 ve 400 Mbit/s) sahip, halihazırda çalışan prod konteynerleri için ayrılmış sınıflardır. Trafik patlamaları sırasında paket kaybını önlemek için, Linux çekirdek sürümüne bağlı olarak her hsfc sınıfına bir qdisc kuyruğu fq veya fq_codel atanır.

Genellikle TC disiplinleri yalnızca giden trafiğe öncelik vermeye yarar. Ancak gelen trafiğe de öncelik vermek istiyoruz; sonuçta, bazı toplu görevler gelen kanalın tamamını kolayca seçebilir, örneğin haritala&azalt için büyük miktarda giriş verisi alabilir. Bunun için modülü kullanıyoruz eğerb, her ağ arayüzü için bir ifbX sanal arayüzü oluşturur ve gelen trafiği arayüzden ifbX'te giden trafiğe yönlendirir. Ayrıca, ifbX için aynı disiplinlerin tümü, hsfc yapılandırmasının çok benzer olacağı giden trafiği kontrol etmek için çalışır:

Deneyler sırasında, hsfc'nin en iyi sonuçları, 1:2 sınıfı öncelikli olmayan toplu/boş trafik, minion makinelerde belirli bir serbest şeritten daha fazla olmayacak şekilde sınırlandırıldığında gösterdiğini öğrendik. Aksi takdirde, öncelikli olmayan trafiğin üretim görevlerinin gecikmesi üzerinde çok fazla etkisi olur. miniond, belirli bir minyonun tüm prod görevlerinin ortalama trafik tüketimini ölçerek her saniye mevcut ücretsiz bant genişliği miktarını belirler ve bunu ağ arayüzü bant genişliğinden çıkarıyoruz küçük bir farkla, yani

Bantlar gelen ve giden trafik için bağımsız olarak tanımlanır. Miniond, yeni değerlere göre öncelikli olmayan sınıf sınırını 1:2 olarak yeniden yapılandırır.

Böylece üç izolasyon sınıfının tamamını uyguladık: prod, Batch ve Idde. Bu sınıflar görevlerin performans özelliklerini büyük ölçüde etkiler. Bu nedenle, bu özelliği hiyerarşinin en üstüne yerleştirmeye karar verdik, böylece hiyerarşik kuyruğun adına bakıldığında neyle karşı karşıya olduğumuzu hemen anlayabiliriz:

Bütün arkadaşlarımız ağ и müzik cepheler daha sonra prod altındaki hiyerarşiye yerleştirilir. Örneğin toplu iş altına hizmeti yerleştirelim müzik kataloğuOdnoklassniki'ye yüklenen bir dizi mp3 dosyasından periyodik olarak bir parça kataloğu derleyen. Boşta durumdaki bir hizmetin örneği şöyle olabilir: müzik transformatörü, müzik ses seviyesini normalleştirir.

Ekstra satırların tekrar kaldırılmasıyla, görev izolasyon sınıfını tam hizmet adının sonuna ekleyerek hizmet adlarımızı daha düz yazabiliriz: web.front.prod, katalog.müzik.toplu, transformatör.müzik.idle.

Ve şimdi, hizmetin adına baktığımızda, yalnızca hangi işlevi yerine getirdiğini değil, aynı zamanda izolasyon sınıfını, yani kritikliğini vb. anlıyoruz.

Her şey harika ama acı bir gerçek var. Tek bir makinede yürütülen görevleri tamamen izole etmek imkansızdır.

Neyi başarmayı başardık: eğer parti yoğun olarak tüketiyorsa sadece CPU kaynakları, daha sonra yerleşik Linux CPU zamanlayıcı işini çok iyi yapar ve üretim görevi üzerinde pratik olarak hiçbir etkisi olmaz. Ancak bu toplu görev hafızayla aktif olarak çalışmaya başlarsa, o zaman karşılıklı etki zaten ortaya çıkar. Bunun nedeni üretim görevinin işlemcinin bellek önbelleklerinden "silinmesi"dir; bunun sonucunda önbellek kayıpları artar ve işlemci, üretim görevini daha yavaş işler. Böyle bir toplu görev, tipik ürün konteynerimizin gecikmesini %10 artırabilir.

Modern ağ kartlarının dahili bir paket kuyruğuna sahip olması nedeniyle trafiği izole etmek daha da zordur. Toplu görevden gelen paket oraya ilk ulaşırsa, kablo üzerinden ilk iletilen paket olacaktır ve bu konuda hiçbir şey yapılamaz.

Ek olarak, şu ana kadar yalnızca TCP trafiğini önceliklendirme sorununu çözmeyi başardık: hsfc yaklaşımı UDP için işe yaramıyor. Ve TCP trafiği durumunda bile, toplu görev çok fazla trafik oluşturuyorsa, bu aynı zamanda üretim görevinin gecikmesinde de yaklaşık %10'luk bir artış sağlar.

hata toleransı

Tek bulutu geliştirirken hedeflerden biri Odnoklassniki'nin hata toleransını artırmaktı. Bu nedenle, bundan sonra olası arıza ve kaza senaryolarını daha ayrıntılı olarak ele almak istiyorum. Basit bir senaryoyla başlayalım: Bir konteyner arızası.

Konteynerin kendisi çeşitli şekillerde başarısız olabilir. Bu, manifest dosyasındaki bir tür deneme, hata veya hata olabilir; bu nedenle prod görevi, manifestte belirtilenden daha fazla kaynak tüketmeye başlar. Bir vakamız vardı: Bir geliştirici karmaşık bir algoritma uyguladı, onu birçok kez yeniden çalıştı, kendini fazla düşündü ve kafası o kadar karıştı ki sonuçta sorun hiç de önemsiz olmayan bir şekilde döngüye girdi. Ve prod görevi aynı minyonlardaki diğerlerinden daha yüksek önceliğe sahip olduğundan, mevcut tüm işlemci kaynaklarını tüketmeye başladı. Bu durumda izolasyon, daha doğrusu CPU zaman kotası günü kurtardı. Bir göreve kota tahsis edilmişse görev daha fazla tüketmez. Bu nedenle, aynı makinede çalışan toplu iş ve diğer üretim görevleri hiçbir şey fark etmedi.

İkinci olası sorun ise konteynerin düşmesidir. Ve burada yeniden başlatma politikaları bizi kurtarıyor, bunları herkes biliyor, Docker'ın kendisi harika bir iş çıkarıyor. Hemen hemen tüm üretim görevlerinin her zaman yeniden başlatma politikası vardır. Bazen toplu görevler veya ürün kaplarında hata ayıklamak için on_failure kullanırız.

Bir minyonun tamamı müsait değilse ne yapabilirsiniz?

Açıkçası, kabı başka bir makinede çalıştırın. Buradaki ilginç kısım, konteynere atanan IP adres(ler)ine ne olacağıdır.

Konteynerlere, bu konteynerlerin çalıştığı minion makinelerle aynı IP adreslerini atayabiliriz. Daha sonra konteyner başka bir makinede başlatıldığında IP adresi değişir ve tüm istemcilerin konteynerin taşındığını anlaması gerekir ve artık ayrı bir Hizmet Keşif hizmeti gerektiren farklı bir adrese gitmeleri gerekir.

Hizmet Keşfi kullanışlıdır. Bir hizmet kaydını düzenlemek için piyasada farklı derecelerde hata toleransına sahip birçok çözüm vardır. Genellikle bu tür çözümler yük dengeleyici mantığını uygular, ek yapılandırmayı KV depolama vb. biçiminde depolar.
Ancak ayrı bir kayıt defteri uygulamasına gerek kalmamasını istiyoruz çünkü bu, üretimdeki tüm hizmetlerin kullandığı kritik bir sistemin devreye sokulması anlamına gelecektir. Bu, bunun potansiyel bir başarısızlık noktası olduğu ve hataya dayanıklı bir çözüm seçmeniz veya geliştirmeniz gerektiği anlamına gelir; bu da açıkça çok zor, zaman alıcı ve pahalıdır.

Ve bir büyük dezavantaj daha: Eski altyapımızın yenisiyle çalışabilmesi için, bir tür Hizmet Keşif sistemini kullanmak üzere tüm görevleri kesinlikle yeniden yazmamız gerekecekti. Çok fazla iş var ve bazı yerlerde, işletim sistemi çekirdeği düzeyinde veya doğrudan donanımla çalışan düşük seviyeli cihazlar söz konusu olduğunda bu neredeyse imkansız. Bu işlevselliğin aşağıdakiler gibi yerleşik çözüm modellerini kullanarak uygulanması: yan araba bazı yerlerde ek yük, diğerlerinde ise çalışmanın karmaşıklığı ve ek arıza senaryoları anlamına gelir. İşleri karmaşıklaştırmak istemediğimizden Hizmet Keşfinin kullanımını isteğe bağlı hale getirmeye karar verdik.

Tek bulutta IP konteyneri takip eder, yani her görev örneğinin kendi IP adresi vardır. Bu adres "statiktir": hizmet buluta ilk gönderildiğinde her örneğe atanır. Bir hizmetin ömrü boyunca farklı sayıda örneği varsa, sonunda maksimum örneklerin sayısı kadar IP adresi atanacaktır.

Daha sonra bu adresler değişmez: bir kez atanırlar ve hizmetin üretimdeki ömrü boyunca var olmaya devam ederler. IP adresleri ağdaki kapsayıcıları takip eder. Konteyner başka bir köleye devredilirse adres onu takip edecektir.

Bu nedenle, bir hizmet adının IP adresleri listesine eşlenmesi çok nadiren değişir. Yazının başında bahsettiğimiz servis örneklerinin isimlerine tekrar bakarsanız (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), DNS'de kullanılan FQDN'lere benzediklerini fark edeceğiz. Doğru, hizmet örneklerinin adlarını IP adresleriyle eşleştirmek için DNS protokolünü kullanıyoruz. Ayrıca, bu DNS, hem çalışan hem de durdurulmuş tüm kapsayıcıların tüm ayrılmış IP adreslerini döndürür (diyelim ki üç kopya kullanıldı ve orada ayrılmış beş adresimiz var - beşi de döndürülecek). Bu bilgiyi alan müşteriler, beş kopyanın tümü ile bağlantı kurmaya çalışacak ve böylece çalışan kopyaları belirleyecek. Kullanılabilirliği belirlemeye yönelik bu seçenek çok daha güvenilirdir; DNS veya Hizmet Keşfi'ni içermez; bu, bu sistemlerin bilgi uygunluğunu ve hata toleransını sağlamada çözülmesi gereken zor sorunların olmadığı anlamına gelir. Üstelik tüm portalın çalışmasının bağlı olduğu kritik hizmetlerde DNS'yi hiç kullanamıyoruz, sadece IP adreslerini yapılandırmaya giriyoruz.

Konteynerlerin arkasında bu tür bir IP aktarımının uygulanması önemsiz olmayabilir ve bunun nasıl çalıştığına aşağıdaki örnekle bakacağız:

Diyelim ki tek bulut yöneticisi minion M1'e çalıştırma komutunu veriyor 1.ok-web.group1.web.front.prod 1.1.1.1 adresiyle. Minion'da çalışıyor BIRDbu adresi özel sunuculara tanıtan rota reflektörü. İkincisi, M1.1.1.1'deki 1 adresinin yolunun çevrildiği ağ donanımıyla bir BGP oturumuna sahiptir. M1, Linux kullanarak konteynerin içindeki paketleri yönlendirir. Üç adet rota yansıtıcı sunucu vardır, çünkü bu, tek bulut altyapısının çok kritik bir parçasıdır; bunlar olmadan, tek buluttaki ağ çalışmaz. Üçünün de aynı anda arızalanma olasılığını azaltmak için bunları mümkünse veri merkezinin farklı odalarına yerleştirilmiş farklı raflara yerleştiriyoruz.

Şimdi tek bulut yöneticisi ile M1 minion'u arasındaki bağlantının kesildiğini varsayalım. Tek bulut yöneticisi artık M1'in tamamen başarısız olduğu varsayımıyla hareket edecek. Yani M2 minion'a fırlatma komutunu verecek web.group1.web.front.prod aynı adresle 1.1.1.1. Artık ağda 1.1.1.1 için birbiriyle çelişen iki rotamız var: M1 ve M2'de. Bu tür çakışmaları çözmek için BGP duyurusunda belirtilen Çoklu Çıkış Ayırıcıyı kullanıyoruz. Bu, reklamı yapılan rotanın ağırlığını gösteren bir sayıdır. Çakışan rotalar arasından MED değeri daha düşük olan rota seçilecektir. Tek bulut yöneticisi, konteyner IP adreslerinin ayrılmaz bir parçası olarak MED'i destekler. İlk defa, adres yeterince büyük bir MED = 1 ile yazılmıştır.Böyle bir acil konteyner transferi durumunda, master MED'i azaltır ve M000, 000 adresini MED = ile duyurma komutunu zaten alacaktır. 2. M1.1.1.1'de çalışan örnek, bu durumda hiçbir bağlantı olmadığında kalacak ve eski bir çekim gibi durdurulacağı efendiyle bağlantı yeniden sağlanana kadar onun sonraki kaderi bizi pek ilgilendirmiyor.

Аварии

Tüm veri merkezi yönetim sistemleri küçük arızaları her zaman kabul edilebilir bir şekilde ele alır. Konteyner taşması neredeyse her yerde normaldir.

Veri merkezinin bir veya daha fazla odasındaki elektrik kesintisi gibi acil durumları nasıl ele aldığımıza bakalım.

Bir veri merkezi yönetim sistemi için kaza ne anlama gelir? Her şeyden önce, bu, birçok makinenin tek seferlik büyük bir arızasıdır ve kontrol sisteminin aynı anda çok sayıda konteyneri taşıması gerekir. Ancak felaket çok büyük ölçekliyse, veri merkezinin kaynak kapasitesi yükün %100'ünün altına düştüğü için tüm görevler diğer kölelere yeniden tahsis edilemeyebilir.

Çoğu zaman kazalara kontrol katmanındaki arızalar eşlik eder. Bu, ekipmanının arızalanması nedeniyle meydana gelebilir, ancak daha çok kazaların test edilmemesi ve artan yük nedeniyle kontrol katmanının kendisinin düşmesi nedeniyle meydana gelebilir.

Bütün bunlar hakkında ne yapabilirsiniz?

Toplu geçişler, altyapıda çok sayıda etkinliğin, geçişin ve dağıtımın meydana geldiği anlamına gelir. Taşımaların her biri, konteyner görüntülerini minyonlara teslim etmek ve paketinden çıkarmak, konteynerleri başlatmak ve başlatmak vb. için biraz zaman alabilir. Bu nedenle, daha az önemli olanlardan önce daha önemli görevlerin başlatılması arzu edilir.

Aşina olduğumuz hizmet hiyerarşisine tekrar bakalım ve hangi görevleri ilk önce çalıştırmak istediğimize karar vermeye çalışalım.

Elbette bunlar doğrudan kullanıcı isteklerinin işlenmesiyle ilgili süreçlerdir, yani prod. Bunu şununla belirtiyoruz yerleştirme önceliği — kuyruğa atanabilecek bir numara. Bir kuyruğun önceliği daha yüksekse hizmetleri ilk sıraya alınır.

Prod'da daha yüksek öncelikler atarız, 0; toplu olarak - biraz daha düşük, 100; boştayken - daha da düşük, 200. Öncelikler hiyerarşik olarak uygulanır. Hiyerarşide daha düşük olan tüm görevler karşılık gelen bir önceliğe sahip olacaktır. Prod içindeki önbelleklerin ön uçlardan önce başlatılmasını istiyorsak, ön uçlara öncelikleri önbellek = 0 ve ön alt kuyruklara = 1 atarız. Örneğin, ana portalın önce ön uçlardan ve yalnızca müzik ön kısmından başlatılmasını istiyorsak o zaman ikincisine - 10 - daha düşük bir öncelik atayabiliriz.

Bir sonraki sorun kaynak eksikliğidir. Bu nedenle, büyük miktarda ekipman, veri merkezinin tüm salonları arızalandı ve o kadar çok hizmeti yeniden başlattık ki artık herkese yetecek kaynak yok. Ana kritik hizmetlerin çalışır durumda kalması için hangi görevlerden fedakarlık edeceğinize karar vermeniz gerekir.

Yerleştirme önceliğinden farklı olarak, tüm toplu görevleri ayrım gözetmeden feda edemeyiz; bunlardan bazıları portalın çalışması için önemlidir. Bu nedenle ayrı ayrı vurguladık. ön alım önceliği görevler. Yerleştirildiğinde, daha yüksek öncelikli bir görev, daha fazla ücretsiz minyon yoksa daha düşük öncelikli bir görevi önleyebilir, yani durdurabilir. Bu durumda, düşük önceliğe sahip bir görev muhtemelen yerine getirilmeden kalacaktır, yani yeterli boş kaynağa sahip, artık bu görev için uygun bir minyon olmayacaktır.

Hiyerarşimizde, boşta kalma için 200'e eşit bir öncelik belirleyerek, üretim ve toplu görevlerin boşta olan görevleri önleyeceği veya durduracağı, ancak birbirlerini değil, bir önleme önceliği belirlemek çok basittir. Tıpkı yerleştirme önceliği durumunda olduğu gibi, Daha karmaşık kuralları tanımlamak için hiyerarşimizi kullanabiliriz. Örneğin, ana web portalı için yeterli kaynağımız yoksa, ilgili düğümlerin önceliğini daha düşük bir değere ayarlayarak müzik işlevini feda ettiğimizi belirtelim: 10.

Tüm DC kazaları

Neden tüm veri merkezi başarısız olabilir? Öğe. İyi bir yazıydı kasırga veri merkezinin çalışmasını etkiledi. Unsurlar, bir zamanlar manifolddaki optikleri yakan ve veri merkezinin diğer sitelerle bağlantısını tamamen kaybeden evsizler olarak düşünülebilir. Başarısızlığın nedeni aynı zamanda insan faktörü de olabilir: Operatör öyle bir komut verecek ki tüm veri merkezi düşecek. Bunun nedeni büyük bir hata olabilir. Genel olarak veri merkezlerinin çökmesi nadir görülen bir durum değildir. Bu birkaç ayda bir başımıza gelir.

Ve biz de kimsenin #canlı tweet atmasını önlemek için bunu yapıyoruz.

İlk strateji izolasyondur. Her bir bulut örneği yalıtılmıştır ve makineleri yalnızca tek bir veri merkezinde yönetebilir. Yani bir bulutun hatalar veya yanlış operatör komutları nedeniyle kaybı, yalnızca bir veri merkezinin kaybıdır. Biz buna hazırız: Uygulamanın ve verinin replikalarının tüm veri merkezlerinde bulunduğu bir yedekleme politikamız var. Hataya dayanıklı veritabanları kullanıyoruz ve periyodik olarak hataları test ediyoruz.
Bugünden beri dört veri merkezimiz var; bu, tek bulutun dört ayrı, tamamen izole edilmiş örneği anlamına geliyor.

Bu yaklaşım yalnızca fiziksel arızaya karşı koruma sağlamakla kalmaz, aynı zamanda operatör hatasına karşı da koruma sağlayabilir.

İnsan faktörüyle başka neler yapılabilir? Bir operatör buluta tuhaf veya potansiyel olarak tehlikeli bir komut verdiğinde, ne kadar iyi düşündüğünü görmek için aniden küçük bir sorunu çözmesi istenebilir. Örneğin, bu, birçok kopyanın toplu olarak durdurulması veya yalnızca garip bir komutsa, kopyaların sayısını azaltmak veya yalnızca yeni bildirimdeki sürüm numarasını değil, görüntünün adını değiştirmek.

sonuçlar

Tek bulutun ayırt edici özellikleri:

• Hizmetler ve kapsayıcılar için hiyerarşik ve görsel adlandırma şemasıBu, görevin ne olduğunu, neyle ilgili olduğunu, nasıl çalıştığını ve bundan kimin sorumlu olduğunu çok hızlı bir şekilde öğrenmenizi sağlar.
• Biz uyguluyoruz ürün ve partiyi birleştirme tekniğiMakine paylaşımının verimliliğini artırmak için köleler üzerinde görevler. Cpuset yerine CPU kotalarını, paylaşımlarını, CPU zamanlayıcı politikalarını ve Linux QoS'yi kullanıyoruz.
• Aynı makinede çalışan konteynerleri tamamen izole etmek mümkün olmadı ancak karşılıklı etkileri %20 dahilinde kalıyor.
• Hizmetlerin bir hiyerarşi halinde düzenlenmesi, aşağıdakileri kullanarak otomatik olağanüstü durum kurtarmaya yardımcı olur: yerleştirme ve ön alım öncelikleri.

SSS

Neden hazır bir çözümü kabul etmedik?

• Farklı görev izolasyon sınıfları, minyonlara yerleştirildiğinde farklı mantık gerektirir. Üretim görevleri yalnızca kaynakları ayırarak yerleştirilebiliyorsa, o zaman toplu ve boşta olan görevler, minion makinelerde kaynakların gerçek kullanımını takip ederek yerleştirilmelidir.
• Görevler tarafından tüketilen kaynakların dikkate alınması ihtiyacı, örneğin:
  • Şebeke bant genişliği;
  • Disklerin türleri ve “milleri”.
• Acil müdahale sırasında hizmetlerin önceliklerini, tek buluttaki hiyerarşik kuyruklar kullanılarak çözülen kaynaklara yönelik komutların haklarını ve kotalarını belirtme ihtiyacı.
• Kazalara ve olaylara müdahale süresini kısaltmak için konteynerlere insanlar tarafından isim verilmesi ihtiyacı
• Hizmet Keşfinin tek seferlik yaygın bir şekilde uygulanmasının imkansızlığı; donanım ana bilgisayarlarında barındırılan görevlerle uzun süre bir arada var olma ihtiyacı - bu, konteynerleri takip eden "statik" IP adresleri ile çözülen bir şeydir ve sonuç olarak, büyük bir ağ altyapısıyla benzersiz entegrasyon ihtiyacı.

Tüm bu işlevler, mevcut çözümlerde bize uyacak şekilde önemli değişiklikler yapılmasını gerektiriyordu ve iş miktarını değerlendirdikten sonra, yaklaşık olarak aynı işçilik maliyetleriyle kendi çözümümüzü geliştirebileceğimizi fark ettik. Ancak çözümünüzün çalıştırılması ve geliştirilmesi çok daha kolay olacaktır; ihtiyacımız olmayan işlevselliği destekleyen gereksiz soyutlamalar içermez.

Son satırları okuyanlara sabrınız ve ilginiz için teşekkür ederiz!

Kaynak: habr.com