Saniyede bir petabaytın üzerinde tepe ikiye bölme bant genişliğine sahip 100 bin sunucudan daha büyük bilgi işlem kümelerinin konuşlandırılmasına olanak tanıyan bir veri merkezi ağ tasarımı geliştirdik.
Dmitry Afanasyev'in raporundan yeni tasarımın temel ilkelerini, topolojileri ölçeklendirmeyi, bununla ortaya çıkan sorunları, bunları çözme seçeneklerini, modern ağ cihazlarının yönlendirme düzlemi işlevlerini "yoğun bağlı" olarak yönlendirme ve ölçeklendirme özelliklerini öğreneceksiniz. Çok sayıda ECMP yoluna sahip topolojiler. Ayrıca Dima, harici bağlantının organizasyonu, fiziksel katman, kablolama sistemi ve kapasiteyi daha da artırmanın yolları hakkında kısaca konuştu.
- Herkese iyi günler! Adım Dmitry Afanasyev, Yandex'de ağ mimarıyım ve öncelikle veri merkezi ağları tasarlıyorum.
Hikayem Yandex veri merkezlerinin güncellenen ağı hakkında olacak. Bu, sahip olduğumuz tasarımın bir evrimi ama aynı zamanda bazı yeni unsurlar da var. Bu bir genel bakış sunumudur çünkü kısa bir süreye sığdırılacak çok fazla bilgi vardı. Mantıksal bir topoloji seçerek başlayacağız. Daha sonra kontrol düzlemine genel bir bakış ve veri düzlemi ölçeklenebilirliği ile ilgili sorunlar, fiziksel düzeyde ne olacağına dair bir seçim olacak ve cihazların bazı özelliklerine bakacağız. Biraz önce bahsettiğimiz MPLS ile veri merkezinde neler olup bittiğine biraz değinelim.
Peki, yükler ve hizmetler açısından Yandex nedir? Yandex tipik bir hiper ölçekleyicidir. Kullanıcılara baktığımızda öncelikle kullanıcı isteklerini işliyoruz. Ayrıca çeşitli akış hizmetleri ve veri aktarımı, çünkü depolama hizmetlerimiz de var. Arka uca daha yakınsa, dağıtılmış nesne depolama, veri çoğaltma ve elbette kalıcı kuyruklar gibi altyapı yükleri ve hizmetleri orada görünür. Ana iş yükü türlerinden biri MapReduce ve benzeri sistemler, akış işleme, makine öğrenimi vb.'dir.
Bütün bunların gerçekleşeceği altyapı nasıl? Yine, oldukça tipik bir hiper ölçekleyiciyiz, ancak belki de spektrumun daha az hiper ölçekleyici tarafına biraz daha yakınız. Ama tüm özelliklere sahibiz. Mümkün olan her yerde emtia donanımını ve yatay ölçeklendirmeyi kullanıyoruz. Tam kaynak havuzuna sahibiz: Bireysel makinelerle, bireysel raflarla çalışmıyoruz, ancak bunları planlama ve tahsisle ilgilenen bazı ek hizmetlerle birlikte değiştirilebilir kaynaklardan oluşan geniş bir havuzda birleştiriyoruz ve bu havuzun tamamıyla çalışıyoruz.
Yani bir sonraki seviyeye sahibiz: bilgi işlem kümesi seviyesinde işletim sistemi. Kullandığımız teknoloji yığınını tam olarak kontrol etmemiz çok önemli. Uç noktaları (ana bilgisayarları), ağı ve yazılım yığınını kontrol ediyoruz.
Rusya'da ve yurt dışında çok sayıda büyük veri merkezimiz var. MPLS teknolojisini kullanan bir omurga tarafından birleştirilirler. Dahili altyapımız neredeyse tamamen IPv6 üzerine kuruludur, ancak hala esas olarak IPv4 üzerinden gelen harici trafiğe hizmet vermemiz gerektiğinden, bir şekilde IPv4 üzerinden gelen istekleri ön uç sunuculara iletmeliyiz ve biraz daha harici IPv4-İnternet'e gitmeliyiz - örneğin indeksleme için.
Veri merkezi ağ tasarımlarının son birkaç yinelemesinde çok katmanlı Clos topolojileri kullanılmıştır ve yalnızca L3'tür. Bir süre önce L2'den ayrıldık ve rahat bir nefes aldık. Son olarak altyapımız yüzbinlerce bilgi işlem (sunucu) örneğini içerir. Bir süre önce maksimum küme boyutu yaklaşık 10 bin sunucuydu. Bu büyük ölçüde aynı küme düzeyindeki işletim sistemlerinin, zamanlayıcıların, kaynak tahsisinin vb. nasıl çalışabildiğinden kaynaklanmaktadır. Altyapı yazılımı tarafında ilerleme kaydedildiğinden, hedef boyutu artık bir bilgi işlem kümesinde yaklaşık 100 bin sunucudur ve Böyle bir kümede verimli kaynak havuzuna izin veren ağ fabrikaları kurabilmek gibi bir görevimiz var.
Bir veri merkezi ağından ne istiyoruz? Her şeyden önce, çok sayıda ucuz ve oldukça eşit bir şekilde dağıtılmış bant genişliği var. Çünkü ağ, kaynakları bir araya toplayabileceğimiz omurgadır. Yeni hedef boyutu tek bir kümede yaklaşık 100 bin sunucudur.
Elbette ölçeklenebilir ve istikrarlı bir kontrol düzlemi de istiyoruz, çünkü bu kadar büyük bir altyapıda, basit rastgele olaylardan bile pek çok baş ağrısı ortaya çıkıyor ve kontrol düzleminin de bize baş ağrısı getirmesini istemiyoruz. Aynı zamanda içindeki durumu da en aza indirmek istiyoruz. Durum ne kadar küçük olursa, her şey o kadar iyi ve stabil çalışır ve teşhis edilmesi de o kadar kolay olur.
Elbette otomasyona ihtiyacımız var çünkü böyle bir altyapıyı manuel olarak yönetmek mümkün değil ve bir süredir de imkansızdı. Mümkün olduğunca operasyonel desteğe, sağlanabildiği ölçüde CI/CD desteğine ihtiyacımız var.
Bu büyüklükteki veri merkezleri ve kümelerle birlikte, hizmet kesintisi olmadan artımlı dağıtım ve genişlemeyi destekleme görevi oldukça acil hale geldi. Bin makineden oluşan, belki de on bine yakın makineden oluşan kümelerde, bunlar hâlâ tek bir işlem olarak kullanıma sunulabilirse; yani, altyapının genişletilmesini planlıyoruz ve birkaç bin makinenin tek bir işlem olarak eklenmesini planlıyoruz. o zaman yüzbinlerce makine büyüklüğünde bir küme bu şekilde hemen ortaya çıkmaz, belli bir zaman dilimi içinde oluşur. Ve bunca zaman boyunca zaten pompalanmış olanın, konuşlandırılmış altyapının mevcut olması arzu edilir.
Ve sahip olduğumuz ve bıraktığımız bir gereksinim: çoklu kiralama desteği, yani sanallaştırma veya ağ bölümlendirme. Artık bunu ağ yapısı düzeyinde yapmamıza gerek yok çünkü parçalama ana bilgisayarlara gitti ve bu bizim için ölçeklendirmeyi çok kolaylaştırdı. IPv6 ve geniş adres alanı sayesinde dahili altyapıda yinelenen adresler kullanmamıza gerek kalmadı; tüm adreslemeler zaten benzersizdi. Ve hostlara filtreleme ve ağ segmentasyonunu almış olmamız sayesinde, veri merkezi ağlarında herhangi bir sanal ağ varlığı oluşturmamıza gerek kalmıyor.
Çok önemli bir şey ihtiyacımız olmayan şeydir. Bazı işlevler ağdan kaldırılabiliyorsa, bu hayatı çok daha kolaylaştırır ve kural olarak mevcut ekipman ve yazılım seçimini genişleterek tanılamayı çok basit hale getirir.
Peki, her zaman sevinçle olmasa da, süreç tamamlandığında büyük bir rahatlamayla, neye ihtiyacımız yok, nelerden vazgeçebildik?
Her şeyden önce L2'den vazgeçiyorum. Ne gerçek ne de taklit edilmiş L2'ye ihtiyacımız yok. Uygulama yığınını kontrol etmemiz nedeniyle büyük ölçüde kullanılmıyor. Uygulamalarımız yatay olarak ölçeklenebilir, L3 adreslemeyle çalışırlar, bazı bireysel örneklerin ortadan kalkmasından pek endişe etmezler, sadece yeni bir tane yayınlarlar, eski adreste yayınlanmasına gerek yoktur, çünkü kümede bulunan makinelerin ayrı düzeyde hizmet keşfi ve izlenmesi. Bu görevi ağa devretmiyoruz. Ağın görevi paketleri A noktasından B noktasına ulaştırmaktır.
Ayrıca adreslerin ağ içerisinde hareket ettiği durumlarla da karşılaşmıyoruz, bunun da takip edilmesi gerekiyor. Birçok tasarımda buna genellikle VM mobilitesini desteklemek için ihtiyaç duyulur. Büyük Yandex'in iç altyapısında sanal makinelerin mobilitesini kullanmıyoruz ve üstelik bu yapılsa bile ağ desteğiyle olmaması gerektiğine inanıyoruz. Gerçekten yapılması gerekiyorsa, bunun ana bilgisayar düzeyinde yapılması ve alt katmanın (taşıma ağı) yönlendirme sistemine dokunmamak veya çok fazla dinamik değişiklik yapmamak için kaplamalara taşınabilecek adresleri göndermesi gerekir. .
Kullanmadığımız bir diğer teknoloji ise multicast. İsterseniz nedenini detaylı olarak anlatabilirim. Bu, hayatı çok daha kolaylaştırır, çünkü birisi bununla ilgilenirse ve çok noktaya yayın kontrol düzleminin en basit kurulumlar dışında tam olarak neye benzediğine bakmışsa, bu büyük bir baş ağrısıdır. Dahası, örneğin iyi işleyen bir açık kaynak uygulaması bulmak zordur.
Son olarak ağlarımızı çok fazla değişmeyecek şekilde tasarlıyoruz. Yönlendirme sistemindeki harici olayların akışının küçük olduğuna güvenebiliriz.
Bir veri merkezi ağı geliştirirken hangi sorunlar ortaya çıkıyor ve hangi kısıtlamaların dikkate alınması gerekiyor? Maliyet elbette. Ölçeklenebilirlik, büyümek istediğimiz düzey. Hizmeti durdurmadan genişleme ihtiyacı. Bant genişliği, kullanılabilirlik. Operasyonel ekipler için izleme sistemleri için ağda olup bitenlerin görünürlüğü. Otomasyon desteği - yine mümkün olduğunca, çünkü ek katmanların eklenmesi de dahil olmak üzere farklı görevler farklı düzeylerde çözülebilir. Eh, [muhtemelen] satıcılara bağımlı değil. Farklı tarihsel dönemlerde de olsa, hangi bölüme baktığınıza bağlı olarak bu bağımsızlığa ulaşmak daha kolay ya da daha zordu. Ağ cihazı çiplerinin bir kesitini alırsak, yakın zamana kadar, aynı zamanda yüksek verimli çipler istiyorsak, satıcılardan bağımsızlıktan bahsetmek çok koşulluydu.
Ağımızı oluşturmak için hangi mantıksal topolojiyi kullanacağız? Bu çok seviyeli bir Clos olacak. Aslında şu anda gerçek bir alternatif yok. Ve Clos topolojisi, eğer büyük taban anahtarlarımız varsa, şu anda akademik ilgi alanına giren çeşitli gelişmiş topolojilerle karşılaştırıldığında bile oldukça iyidir.
Çok seviyeli bir Clos ağı kabaca nasıl yapılandırılmıştır ve içindeki farklı unsurlar nelerdir? Her şeyden önce, rüzgar nerede kuzey, nerede güney, nerede doğu, nerede batı yönünüzü bulmak için yükseldi. Bu tür ağlar genellikle çok büyük batı-doğu trafiğine sahip olanlar tarafından kurulur. Geri kalan öğelere gelince, üstte daha küçük anahtarlardan oluşan sanal bir anahtar var. Clos ağlarının özyinelemeli inşasının ana fikri budur. Bir çeşit yarıçapa sahip elemanları alıp bunları birleştiriyoruz, böylece elde ettiğimiz şey daha büyük bir yarıçapa sahip bir anahtar olarak değerlendirilebilir. Daha fazlasına ihtiyacınız varsa prosedür tekrarlanabilir.
Örneğin iki seviyeli Clos'un olduğu durumlarda, diyagramımda dikey olan bileşenleri açıkça tanımlamanın mümkün olduğu durumlarda, bunlara genellikle düzlemler denir. Üç seviyeli omurga anahtarlarına (hepsi sınır veya ToR anahtarları değildir ve yalnızca geçiş için kullanılır) sahip bir Clos oluştursaydık, uçaklar daha karmaşık görünürdü; iki seviyeli olanlar tam olarak buna benzer. ToR veya yaprak anahtarlardan oluşan bir blok ve bunlarla ilişkili birinci seviye omurga anahtarlarını Pod olarak adlandırıyoruz. Pod'un tepesindeki omurga-1 seviyesinin omurga anahtarları, Pod'un tepesi olan Pod'un tepesidir. Fabrikanın tamamının üst kısmında yer alan anahtarlar fabrikanın en üst katmanı olan kumaşın üst kısmıdır.
Elbette şu soru ortaya çıkıyor: Clos ağları bir süredir inşa ediliyor; fikir genellikle klasik telefon, TDM ağlarından geliyor. Belki daha iyi bir şey ortaya çıkmıştır, belki daha iyi bir şey yapılabilir? Evet ve hayır. Teorik olarak evet ama pratikte yakın gelecekte kesinlikle hayır. Çok sayıda ilginç topoloji olduğundan bazıları üretimde bile kullanılıyor; örneğin Dragonfly, HPC uygulamalarında kullanılıyor; Xpander, FatClique, Jellyfish gibi ilginç topolojiler de var. Son zamanlarda SIGCOMM veya NSDI gibi konferanslardaki raporlara bakarsanız, Clos'tan daha iyi özelliklere (biri veya diğeri) sahip alternatif topolojiler üzerine oldukça fazla sayıda çalışma bulabilirsiniz.
Ancak tüm bu topolojilerin ilginç bir özelliği var. Emtia donanımı üzerine kurmaya çalıştığımız ve oldukça makul paraya mal olan veri merkezi ağlarında bunların uygulanmasını engelliyor. Tüm bu alternatif topolojilerde bant genişliğinin çoğuna ne yazık ki en kısa yollardan erişilemiyor. Bu nedenle geleneksel kontrol düzlemini kullanma fırsatını hemen kaybediyoruz.
Teorik olarak sorunun çözümü bilinmektedir. Bunlar, örneğin k-en kısa yolu kullanan bağlantı durumunun modifikasyonlarıdır, ancak yine üretimde uygulanacak ve ekipmanda yaygın olarak bulunabilecek bu tür protokoller yoktur.
Üstelik, kapasitenin çoğuna en kısa yollardan erişilemediğinden, bu yolların tümünü seçmek için yalnızca kontrol düzleminde değişiklik yapmamız gerekir (ve bu arada, bu, kontrol düzleminde önemli ölçüde daha fazla durumdur). Hala yönlendirme düzlemini değiştirmemiz gerekiyor ve kural olarak en az iki ek özellik gerekiyor. Bu, örneğin ana bilgisayarda paket iletmeyle ilgili tüm kararları tek seferlik verme yeteneğidir. Aslında bu kaynak yönlendirmedir, bazen ara bağlantı ağları literatüründe buna hepsi bir arada yönlendirme kararları denir. Uyarlanabilir yönlendirme, ağ öğelerinde ihtiyaç duyduğumuz bir işlevdir; bu, örneğin, sıradaki en az yük hakkındaki bilgilere dayanarak bir sonraki atlamayı seçmemiz gerçeğine indirgenir. Örnek olarak başka seçenekler de mümkündür.
Dolayısıyla yön ilginç ama ne yazık ki şu anda uygulayamıyoruz.
Tamam, Clos mantıksal topolojisine karar verdik. Bunu nasıl ölçeklendireceğiz? Nasıl çalıştığını ve neler yapılabileceğini görelim.
Bir Clos ağında, bir şekilde değiştirebileceğimiz ve belirli sonuçlar alabileceğimiz iki ana parametre vardır: öğelerin tabanı ve ağdaki düzey sayısı. Her ikisinin de boyutu nasıl etkilediğine dair şematik bir diyagramım var. İdeal olarak ikisini birleştiriyoruz.
Clos ağının nihai genişliğinin, güney tabanının tüm düzeylerdeki omurga anahtarlarının, kaç bağlantımız olduğu, nasıl dallandığı gibi çarpım olduğu görülebilir. Ağın boyutunu bu şekilde ölçeklendiriyoruz.
Kapasiteyle ilgili olarak, özellikle ToR anahtarlarında iki ölçeklendirme seçeneği vardır. Ya genel topolojiyi korurken daha hızlı bağlantılar kullanabiliriz ya da daha fazla düzlem ekleyebiliriz.
Clos ağının genişletilmiş versiyonuna (sağ alt köşede) bakarsanız ve aşağıdaki Clos ağıyla bu resme dönerseniz...
... o zaman bu tamamen aynı topolojidir, ancak bu slaytta daha kompakt bir şekilde daraltılmış ve fabrikanın düzlemleri üst üste bindirilmiştir. Bu aynı.
Bir Clos ağını ölçeklendirmek rakamlarla nasıl görünüyor? Burada bir ağın maksimum genişliğinin ne kadar elde edilebileceğine, raflarda değilse maksimum sayıda raf, ToR anahtarı veya yaprak anahtarına, omurga seviyeleri için kullandığımız anahtar yarıçapına bağlı olarak elde edebileceğimize dair veriler sağlıyorum ve kaç seviye kullanıyoruz?
Burada kaç rafa sahip olabileceğimiz, kaç sunucuya sahip olabileceğimiz ve tüm bunların raf başına 20 kW'a göre yaklaşık olarak ne kadar tüketebileceği anlatılmaktadır. Biraz önce yaklaşık 100 bin sunuculuk bir küme büyüklüğü hedeflediğimizi belirtmiştim.
Tüm bu tasarımda iki buçuk seçeneğin ilgi çektiği görülüyor. İki katmanlı dikenli ve 64 bağlantı noktalı anahtarlı bir seçenek var, bu da biraz yetersiz kalıyor. Ayrıca, iki seviyeli 128 portlu (radix 128'li) omurga anahtarları veya üç seviyeli radix 32'li anahtarlar için mükemmel uyum sağlayan seçenekler mevcuttur. Ve daha fazla tabanın ve daha fazla katmanın olduğu her durumda, çok büyük bir ağ oluşturabilirsiniz, ancak beklenen tüketime bakarsanız, genellikle gigawatt'lar vardır. Kablo döşemek mümkün ama bu kadar elektriği tek bir yerden almamız pek mümkün değil. Veri merkezlerine ilişkin istatistiklere ve kamuya açık verilere baktığınızda, tahmini kapasitesi 150 MW'ın üzerinde olan çok az sayıda veri merkezi bulabilirsiniz. Daha büyük olanlar genellikle veri merkezi kampüsleridir; birkaç büyük veri merkezi birbirine oldukça yakın konumlanmıştır.
Önemli bir parametre daha var. Sol sütuna bakarsanız kullanılabilir bant genişliği burada listelenir. Clos ağında portların önemli bir kısmının anahtarları birbirine bağlamak için kullanıldığını görmek kolaydır. Kullanılabilir bant genişliği, kullanışlı bir şerit, dışarıda sunuculara verilebilecek bir şeydir. Doğal olarak koşullu bağlantı noktalarından ve özellikle gruptan bahsediyorum. Kural olarak, ağ içindeki bağlantılar sunuculara giden bağlantılardan daha hızlıdır, ancak bant genişliği birimi başına, sunucu ekipmanımıza gönderebildiğimiz kadarıyla, ağın kendisinde hala bir miktar bant genişliği vardır. Ve ne kadar çok seviye yaparsak, bu şeridi dışarıya sağlamanın spesifik maliyeti de o kadar yüksek olur.
Üstelik bu ek bant bile tam olarak aynı değil. Aralıklar kısa olsa da, DAC (doğrudan bağlanan bakır, yani twinax kablolar) veya çok modlu optikler gibi, daha da fazla veya daha az makul paraya mal olan bir şey kullanabiliriz. Daha uzun aralıklara geçtiğimizde, kural olarak bunlar tek modlu optiklerdir ve bu ek bant genişliğinin maliyeti gözle görülür şekilde artar.
Ve yine önceki slayda dönersek, aşırı abonelik olmadan bir Clos ağı oluşturursak, o zaman şemaya bakmak, ağın nasıl kurulduğunu görmek kolaydır - her seviyedeki omurga anahtarlarını ekleyerek, en üstteki şeridin tamamını tekrar ederiz. alt. Artı seviye - artı aynı bant, anahtarlarda önceki seviyedekiyle aynı sayıda bağlantı noktası ve aynı sayıda alıcı-verici. Bu nedenle, omurga anahtarlarının seviye sayısının en aza indirilmesi oldukça arzu edilir.
Bu resme dayanarak, gerçekten tabanı 128 olan anahtarlar gibi bir şey üzerine inşa etmek istediğimiz açıktır.
Burada prensip olarak her şey az önce söylediğimle aynı, bu daha sonra değerlendirilecek bir slayt.
Bu tür anahtarlar olarak seçebileceğimiz seçenekler nelerdir? Artık bu tür ağların nihayet tek çipli anahtarlar üzerine kurulabilmesi bizim için çok sevindirici bir haber. Ve bu çok harika, pek çok güzel özelliği var. Örneğin neredeyse hiçbir iç yapıları yoktur. Bu, daha kolay kırıldıkları anlamına gelir. Her türlü şekilde kırılıyorlar ama neyse ki tamamen kırılıyorlar. Modüler cihazlarda, komşular ve kontrol düzlemi açısından çalışıyor gibi göründüğünde çok sayıda hata (çok rahatsız edici) vardır, ancak örneğin kumaşın bir kısmı kaybolmuştur ve çalışmıyor tam kapasitede. Ve ona giden trafik, tamamen işlevsel olduğu ve aşırı yüklenebileceğimiz gerçeğine dayanarak dengeleniyor.
Veya, örneğin, arka panelde sorunlar ortaya çıkıyor, çünkü modüler cihazın içinde aynı zamanda yüksek hızlı SerDe'ler de var - içi gerçekten karmaşık. İletim elemanları arasındaki işaretler ya senkronize edilir ya da senkronize edilmez. Genel olarak, çok sayıda elemandan oluşan herhangi bir üretken modüler cihaz, kural olarak kendi içinde aynı Clos ağını içerir, ancak teşhis edilmesi çok zordur. Çoğu zaman satıcının kendisinin bile teşhis koyması zordur.
Ayrıca cihazın bozulduğu ancak topolojinin tamamen dışına çıkmadığı çok sayıda arıza senaryosu vardır. Ağımız büyük olduğu için aynı unsurlar arasında dengeleme aktif olarak kullanılıyor, ağ çok düzenli yani her şeyin yolunda olduğu bir yol diğer yoldan farklı değil, bir kısmını kaybetmek bizim için daha karlı. topolojiden gelen cihazların bazılarının çalıştığı, ancak bazılarının çalışmadığı bir durumla sonuçlanması.
Tek çipli cihazların bir sonraki güzel özelliği, daha iyi ve daha hızlı gelişmeleridir. Ayrıca daha iyi kapasiteye sahip olma eğilimindedirler. Bir daire üzerinde sahip olduğumuz büyük monte edilmiş yapıları ele alırsak, aynı hızdaki bağlantı noktaları için raf ünitesi başına kapasite, modüler cihazların kapasitesinin neredeyse iki katıdır. Tek bir çip etrafında oluşturulan cihazlar, modüler olanlardan belirgin şekilde daha ucuzdur ve daha az enerji tüketir.
Ama elbette bunların hepsinin bir nedeni var, dezavantajları da var. İlk olarak, yarıçap neredeyse her zaman modüler cihazlardan daha küçüktür. Eğer 128 bağlantı noktasına sahip bir çip üzerine kurulu bir cihaz alabilirsek, artık birkaç yüz bağlantı noktasına sahip modüler bir cihazı da sorunsuz bir şekilde alabiliriz.
Bu, gözle görülür derecede daha küçük bir yönlendirme tabloları boyutudur ve kural olarak veri düzlemi ölçeklenebilirliğiyle ilgili her şeydir. Sığ tamponlar. Ve kural olarak oldukça sınırlı işlevsellik. Ancak, bu kısıtlamaları biliyorsanız ve zamanında bunları aşmaya özen gösterirseniz veya yalnızca bunları hesaba katarsanız, o zaman bunun o kadar da korkutucu olmadığı ortaya çıktı. Son zamanlarda ortaya çıkan tabanı 128 olan cihazlarda tabanın daha küçük olması artık sorun değil; iki katman halinde omurga oluşturabiliyoruz. Ancak bizim için ilginç olan ikiden küçük bir şey inşa etmek hâlâ imkansız. Tek seviye ile çok küçük kümeler elde edilir. Önceki tasarımlarımız ve gereksinimlerimiz bile hâlâ onları aşıyordu.
Aslına bakılırsa, çözüm birdenbire eşiğine gelmişse hâlâ ölçeklendirmenin bir yolu vardır. Sunucuların bağlandığı son (veya ilk) en düşük seviye ToR anahtarları veya yaprak anahtarları olduğundan, bunlara bir raf bağlamamız gerekmez. Bu nedenle, çözüm yarı yarıya yetersiz kalırsa, alt seviyede büyük yarıçaplı bir anahtar kullanmayı ve örneğin iki veya üç rafı bir anahtara bağlamayı düşünebilirsiniz. Bu da bir seçenek, maliyetleri var ama gayet iyi çalışıyor ve yaklaşık iki katı büyüklüğe ulaşmanız gerektiğinde iyi bir çözüm olabilir.
Özetlemek gerekirse, sekiz fabrika katmanından oluşan iki seviyeli omurgaya sahip bir topoloji üzerine inşa ediyoruz.
Fiziğe ne olacak? Çok basit hesaplamalar. İki düzeyde omurgamız varsa, yalnızca üç düzey anahtarımız olur ve ağda üç kablo bölümü olmasını bekleriz: sunuculardan yaprak anahtarlara, omurga 1'e ve omurga 2'ye. Yapabileceğimiz seçenekler kullanım alanları - bunlar twinax, çok modlu, tek moddur. Ve burada hangi şeridin mevcut olduğunu, ne kadara mal olacağını, fiziksel boyutlarının ne olduğunu, hangi aralıkları kapsayabileceğimizi ve nasıl yükselteceğimizi düşünmemiz gerekiyor.
Maliyet açısından her şey sıralanabilir. Twinax'ler aktif optiklerden önemli ölçüde daha ucuzdur, çok modlu alıcı-vericilerden daha ucuzdur, eğer uçtan uçuş başına alırsanız, 100 gigabit anahtar bağlantı noktasından biraz daha ucuzdur. Ve lütfen unutmayın, tek modlu optiklerden daha az maliyetlidir, çünkü tek modun gerekli olduğu uçuşlarda, veri merkezlerinde çeşitli nedenlerden dolayı CWDM kullanmak mantıklıdır, paralel tek modun (PSM) çalışması ise pek uygun değildir. ile çok büyük paketler elde edilen elyaflar oluyor ve bu teknolojilere odaklanırsak yaklaşık olarak aşağıdaki fiyat hiyerarşisini elde ediyoruz.
Bir not daha: Demonte 100 ila 4x25 multimode portları kullanmak ne yazık ki pek mümkün değil. SFP28 alıcı-vericilerin tasarım özellikleri nedeniyle 28 Gbit QSFP100'den çok daha ucuz değildir. Ve çoklu mod için bu sökme işlemi pek işe yaramıyor.
Diğer bir sınırlama ise bilgi işlem kümelerinin boyutu ve sunucu sayısı nedeniyle veri merkezlerimizin fiziksel olarak büyük olmasıdır. Bu da en az bir uçuşun singlemod ile yapılması gerektiği anlamına geliyor. Yine Pod'ların fiziksel boyutundan dolayı iki adet twinax (bakır kablo) çalıştırmak mümkün olmayacaktır.
Sonuç olarak, fiyatı optimize edersek ve bu tasarımın geometrisini hesaba katarsak, CWDM kullanarak bir twinax aralığı, bir çoklu mod aralığı ve bir tekli mod aralığı elde ederiz. Bu, olası yükseltme yollarını dikkate alır.
Son zamanlarda görünen bu, nereye doğru gidiyoruz ve ne mümkün. En azından hem çok modlu hem de tekli mod için 50 Gigabit SerDe'lere nasıl geçileceği açıktır. Üstelik, 400G için şimdi ve gelecekte tek modlu alıcı-vericilerde neler olduğuna bakarsanız, genellikle 50G SerDe'ler elektrik tarafından geldiğinde bile, şerit başına 100 Gbps zaten optiğe gidebilir. Bu nedenle 50'ye geçmek yerine 100 Gigabit SerDe'ye ve şerit başına 100 Gbps'ye geçiş olması oldukça olası çünkü birçok satıcının vaatlerine göre bunların çok yakında kullanılabilirliği bekleniyor. Görünüşe göre 50G SerDe'lerin en hızlı olduğu dönem çok uzun olmayacak çünkü 100G SerDe'lerin ilk kopyaları neredeyse önümüzdeki yıl piyasaya sürülüyor. Ve bundan bir süre sonra muhtemelen makul bir paraya değecekler.
Fizik seçimiyle ilgili bir nüans daha. Prensip olarak 400G SerDes kullanarak zaten 200 veya 50 Gigabit bağlantı noktasını kullanabiliyoruz. Ancak bunun pek mantıklı olmadığı ortaya çıktı, çünkü daha önce de söylediğim gibi, elbette makul sınırlar içinde, anahtarlar üzerinde oldukça büyük bir yarıçap istiyoruz. 128 istiyoruz. Ve eğer çip kapasitemiz sınırlıysa ve bağlantı hızını arttırırsak, o zaman taban doğal olarak azalır, mucize olmaz.
Ve uçak kullanarak toplam kapasiteyi arttırabiliyoruz, üstelik özel bir maliyet de yok, uçak sayısını da artırabiliyoruz. Ve tabanı kaybedersek, ek bir seviye eklemek zorunda kalacağız, yani mevcut durumda, çip başına mevcut maksimum mevcut kapasiteyle, 100 gigabit bağlantı noktalarını kullanmanın daha verimli olduğu ortaya çıkıyor çünkü size izin veriyorlar daha büyük bir sayı tabanı elde etmek için.
Bir sonraki soru fiziğin nasıl organize edildiğidir, ancak kablo altyapısı açısından. Oldukça komik bir şekilde organize edildiği ortaya çıktı. Yaprak anahtarlar ve birinci seviye dikenler arasındaki kablolama - orada çok fazla bağlantı yok, her şey nispeten basit bir şekilde inşa edilmiş. Ancak bir düzlemi ele alırsak, içeride olan şey, birinci seviyedeki tüm dikenleri ikinci seviyedeki tüm dikenlerle birleştirmemiz gerektiğidir.
Ayrıca, kural olarak, veri merkezinin içinde nasıl görünmesi gerektiğine dair bazı istekler vardır. Örneğin, kabloları gerçekten bir demet halinde birleştirip, yüksek yoğunluklu bir patch panel tamamen tek bir patch panele girecek şekilde çekmek istedik, böylece uzunluk açısından hayvanat bahçesi ortadan kalktı. Bu sorunu çözmeyi başardık. Başlangıçta mantıksal topolojiye bakarsanız, düzlemlerin bağımsız olduğunu, her düzlemin kendi başına inşa edilebileceğini görebilirsiniz. Ancak böyle bir paket eklediğimizde ve bağlantı panelinin tamamını bir bağlantı paneline sürüklemek istediğimizde, farklı düzlemleri tek bir paket içinde karıştırmamız ve bunları bir araya getirilme şekillerinden yeniden paketlemek için optik çapraz bağlantılar şeklinde bir ara yapı sunmamız gerekir. bir segmentte, diğer segmentte nasıl toplanacakları. Bu sayede güzel bir özellik elde ediyoruz: tüm karmaşık anahtarlama rafların ötesine geçmiyor. Bir şeyi çok güçlü bir şekilde iç içe geçirmeniz gerektiğinde, bazen Clos ağlarında denildiği gibi "düzlemleri açmanız" gerektiğinde, hepsi tek bir rafın içinde yoğunlaşır. Raflar arasında geçiş yapan, bireysel bağlantılara kadar çok fazla sökülmüş durumda değiliz.
Kablo altyapısının mantıksal organizasyonu açısından durum böyle görünüyor. Soldaki resimde, çok renkli bloklar, her biri sekiz parça olan birinci seviye omurga anahtar bloklarını ve bunlardan çıkan, omurga-2 anahtar bloklarından gelen demetlerle kesişen dört kablo demetini göstermektedir. .
Küçük kareler kavşakları gösterir. Sol üstte bu tür kesişimlerin bir dökümü var; bu aslında, kabloları tamamen tek bir omurga-512 düzleminin bulunduğu tek bir rafa gelecek şekilde yeniden paketleyen 512 x 2 bağlantı noktası çapraz bağlantı modülüdür. Ve sağda, bu resmin taranması omurga-1 seviyesindeki birkaç Pod ile ilgili olarak biraz daha ayrıntılı ve çapraz bağlantıda nasıl paketlendiği, omurga-2 seviyesine nasıl geldiği görülüyor.
Görünüşe göre bu. Henüz tam olarak monte edilmemiş omurga-2 standı (solda) ve çapraz bağlantı standı. Ne yazık ki orada görülecek pek bir şey yok. Tüm bu yapı şu anda genişletilmekte olan büyük veri merkezlerimizden birinde konuşlandırılıyor. Bu devam eden bir çalışma, daha güzel görünecek, daha iyi doldurulacak.
Önemli bir soru: Mantıksal topolojiyi seçtik ve fiziği oluşturduk. Kontrol düzlemine ne olacak? İşletim deneyiminden oldukça iyi bilinmektedir, bağlantı durumu protokollerinin iyi olduğuna dair çok sayıda rapor vardır, onlarla çalışmak bir zevktir, ancak ne yazık ki yoğun bağlantılı bir topolojide iyi ölçeklenemezler. Ve bunu engelleyen bir ana faktör var; bağlantı durumu protokollerinde taşma bu şekilde çalışır. Flood algoritmasını alıp ağımızın nasıl yapılandırıldığına bakarsanız, her adımda çok büyük bir yayılım olacağını ve bunun kontrol düzlemini güncellemelerle dolduracağını görebilirsiniz. Spesifik olarak, bu tür topolojiler, bağlantı durumu protokollerindeki geleneksel taşma algoritmasıyla çok zayıf bir şekilde karışır.
Seçim BGP kullanmaktır. Doğru şekilde nasıl hazırlanacağı, BGP'nin büyük veri merkezlerinde kullanımına ilişkin RFC 7938'de açıklanmaktadır. Temel fikirler basittir: Ana bilgisayar başına minimum ön ek sayısı ve genellikle ağdaki minimum ön ek sayısı, mümkünse toplamanın kullanılması ve yol aramanın engellenmesi. Vadisiz olarak adlandırılan, güncellemelerin çok dikkatli, çok kontrollü bir şekilde dağıtılmasını istiyoruz. Güncellemelerin ağdan geçerken tam olarak bir kez dağıtılmasını istiyoruz. Alttan geliyorlarsa, birden fazla kez açılmadan yukarı çıkarlar. Zigzaglar olmamalıdır. Zigzaglar çok kötü.
Bunu yapmak için temeldeki BGP mekanizmalarını kullanacak kadar basit bir tasarım kullanıyoruz. Yani, yerel bağlantı üzerinde çalışan eBGP kullanıyoruz ve otonom sistemler şu şekilde atanıyor: ToR'da otonom bir sistem, bir Pod'un omurga-1 anahtarlarının tüm bloğunda otonom bir sistem ve Top'un tamamında genel bir otonom sistem. Kumaş. BGP'nin normal davranışının bile bize istediğimiz güncelleme dağılımını verdiğini görmek ve görmek zor değil.
Doğal olarak adresleme ve adres toplamanın, yönlendirmenin oluşturulma şekliyle uyumlu olacak ve kontrol düzleminin kararlılığını sağlayacak şekilde tasarlanması gerekir. Aktarımdaki L3 adreslemesi topolojiye bağlıdır, çünkü bu olmadan toplama elde etmek imkansızdır; bu olmadan bireysel adresler yönlendirme sistemine sızacaktır. Ve bir şey daha, toplama ne yazık ki çok yollu ile pek iyi karışmıyor, çünkü çok yollu olduğumuzda ve toplamaya sahip olduğumuzda, her şey yolundadır, tüm ağ sağlıklı olduğunda, içinde herhangi bir arıza olmaz. Ne yazık ki ağda arızalar ortaya çıktığı ve topolojinin simetrisi kaybolduğu anda birimin duyurulduğu noktaya gelebiliyoruz, oradan da gitmemiz gereken yere gidemiyoruz. Bu nedenle, daha fazla çoklu yolun olmadığı yerde toplamak en iyisidir; bizim durumumuzda bunlar ToR anahtarlarıdır.
Aslında toplamak mümkündür ama dikkatli bir şekilde. Ağ arızaları oluştuğunda kontrollü ayrıştırma yapabilirsek. Ancak bu oldukça zor bir iş, hatta bunu yapmanın mümkün olup olmadığını, ek otomasyon eklemenin mümkün olup olmadığını ve istenen davranışı elde etmek için BGP'yi doğru şekilde başlatacak sonlu durum makinelerinin mümkün olup olmadığını merak ettik. Ne yazık ki, köşe vakalarının işlenmesi çok açık değildir ve karmaşıktır ve bu görev, BGP'ye harici ekler eklenerek tam olarak çözülemez.
Bir sonraki raporda ele alınacak olan RIFT protokolü çerçevesinde bu konuda çok ilginç çalışmalar yapıldı.
Bir diğer önemli konu da çok sayıda alternatif yola sahip olduğumuz yoğun topolojilerde veri düzlemlerinin nasıl ölçeklendiğidir. Bu durumda birkaç ek veri yapısı kullanılır: ECMP grupları, bunlar da Next Hop gruplarını tanımlar.
Normal çalışan, hatasız çalışan bir ağda Clos topolojisine çıktığımızda sadece bir grup kullanmamız yeterli oluyor, çünkü local olmayan her şey varsayılan olarak tanımlanıyor, yukarı çıkabiliyoruz. Yukarıdan aşağıya, güneye doğru gittiğimizde tüm yollar ECMP değil, tek yollu yollardır. Herşey yolunda. Sorun şu ki, klasik Clos topolojisinin özelliği, kumaşın tepesine baktığımızda, herhangi bir öğenin, aşağıdaki herhangi bir öğeye giden tek bir yol olmasıdır. Bu yol boyunca arızalar meydana gelirse, fabrikanın tepesindeki bu özel öğe, tam olarak bozuk yolun arkasında bulunan önekler için geçersiz hale gelir. Ancak geri kalanı için bu geçerlidir ve ECMP gruplarını ayrıştırıp yeni bir durum tanıtmamız gerekir.
Modern cihazlarda veri düzlemi ölçeklenebilirliği nasıl görünür? LPM (en uzun önek eşleşmesi) yaparsak her şey oldukça iyi olur, 100'in üzerinde önek. Next Hop gruplarından bahsediyorsak her şey daha kötü, 2-4 bin. Sonraki Atlamaların (veya bitişikliklerin) açıklamasını içeren bir tablodan bahsediyorsak, bu 16k ile 64k arasında bir yerdedir. Ve bu bir sorun haline gelebilir. Ve burada ilginç bir konuya geliyoruz: veri merkezlerinde MPLS'ye ne oldu? Prensip olarak bunu yapmak istedik.
İki şey oldu. Ana bilgisayarlar üzerinde mikro segmentasyon yaptık; artık bunu ağ üzerinde yapmamıza gerek kalmadı. Farklı satıcıların desteğiyle pek iyi değildi ve MPLS'li beyaz kutulardaki açık uygulamalarla daha da iyi oldu. Ve MPLS, en azından geleneksel uygulamaları ne yazık ki ECMP ile çok zayıf birleşiyor. Ve bu yüzden.
IP için ECMP yönlendirme yapısı böyle görünür. Çok sayıda önek aynı grubu ve aynı Next Hops bloğunu (veya bitişiklikleri, farklı aygıtlar için farklı belgelerde farklı şekilde adlandırılabilir) kullanabilir. Buradaki önemli nokta, bunun giden bağlantı noktası olarak tanımlanması ve doğru Sonraki Hop'a ulaşmak için MAC adresinin yeniden yazılması gerektiğidir. IP için her şey basit görünüyor; aynı grup, aynı Next Hops bloğu için çok sayıda önek kullanabilirsiniz.
Klasik MPLS mimarisi, giden arayüze bağlı olarak etiketin farklı değerlere yeniden yazılabileceğini ima eder. Bu nedenle her giriş etiketi için bir grup ve bir Sonraki Hops bloğu tutmamız gerekiyor. Ve ne yazık ki bu ölçeklenmiyor.
Tasarımımızda yaklaşık 4000 ToR anahtarına ihtiyacımız olduğunu görmek kolaydır; eğer omurga-64'den omurga-1'ye doğru hareket edersek maksimum genişlik 2 ECMP yoluydu. ToR'lu yalnızca bir önek kaybolursa ECMP gruplarından oluşan bir tabloya zar zor girebiliyoruz ve Sonraki Hops tablosuna hiç giremiyoruz.
Her şey umutsuz değil çünkü Segment Yönlendirme gibi mimariler küresel etiketleri içeriyor. Resmi olarak tüm bu Next Hops bloklarını yeniden çökertmek mümkün olacaktır. Bunu yapmak için joker karakter tipi bir işleme ihtiyacınız var: bir etiket alın ve onu belirli bir değer olmadan aynı etikete yeniden yazın. Ancak ne yazık ki mevcut uygulamalarda bu pek mevcut değil.
Son olarak dış trafiği veri merkezine getirmemiz gerekiyor. Nasıl yapılır? Daha önce Clos ağına trafik yukarıdan sağlanıyordu. Yani kumaşın üst kısmında tüm cihazlara bağlanan kenar yönlendiriciler vardı. Bu çözüm küçük ve orta boyutlarda oldukça iyi çalışır. Ne yazık ki, trafiği bu şekilde tüm ağa simetrik olarak göndermek için, Kumaşın Üstü'nün tüm elemanlarına aynı anda ulaşmamız gerekiyor ve bunlardan yüzden fazla olduğunda, aynı zamanda büyük bir alana da ihtiyacımız olduğu ortaya çıkıyor. kenar yönlendiricilerdeki radix. Genel olarak bu maliyetlidir çünkü kenar yönlendiriciler daha işlevseldir, üzerlerindeki bağlantı noktaları daha pahalı olacaktır ve tasarım pek güzel değildir.
Başka bir seçenek de bu tür trafiği aşağıdan başlatmaktır. Clos topolojisinin, aşağıdan, yani ToR tarafından gelen trafiğin, iki yinelemede tüm kumaşın üst kısmı boyunca seviyeler arasında eşit olarak dağıtılarak tüm ağı yükleyecek şekilde oluşturulduğunu doğrulamak kolaydır. Bu nedenle, harici bağlantı sağlayan özel bir Pod türü olan Edge Pod'u tanıtıyoruz.
Bir seçenek daha var. Mesela Facebook'un yaptığı da budur. Buna Yapı Toplayıcı veya HGRID diyorlar. Birden fazla veri merkezini bağlamak için ek bir omurga seviyesi tanıtılıyor. Arayüzlerde ek fonksiyonlarımız veya kapsülleme değişikliklerimiz yoksa bu tasarım mümkündür. Bunlar ek temas noktalarıysa, bu zordur. Tipik olarak daha fazla işlev ve veri merkezinin farklı bölümlerini ayıran bir tür zar vardır. Böyle bir zarı büyütmenin bir anlamı yok, ancak bir nedenden dolayı gerçekten ihtiyaç duyuluyorsa, o zaman onu alıp mümkün olduğu kadar genişletip konakçılara aktarma olasılığını düşünmek mantıklıdır. Bu, örneğin birçok bulut operatörü tarafından yapılır. Kaplamaları var, ana bilgisayarlardan başlıyorlar.
Hangi gelişim fırsatlarını görüyoruz? Her şeyden önce, CI/CD hattına yönelik desteğin iyileştirilmesi. Test ettiğimiz şekilde uçmak ve uçma şeklimizi test etmek istiyoruz. Bu pek işe yaramıyor çünkü altyapı büyük ve bunu testler için kopyalamak imkansız. Test öğelerini üretim altyapısına bırakmadan nasıl dahil edeceğinizi anlamalısınız.
Daha iyi enstrümantasyon ve daha iyi izleme neredeyse hiçbir zaman gereksiz değildir. Sorunun tamamı çaba ve geri dönüş dengesidir. Makul bir çabayla ekleyebilirseniz, çok iyi.
Ağ cihazları için işletim sistemlerini açın. RIFT gibi daha iyi protokoller ve daha iyi yönlendirme sistemleri. Daha iyi tıkanıklık kontrol şemalarının kullanılması ve belki de en azından bazı noktalarda kümelenme içinde RDMA desteğinin tanıtılması konusunda da araştırmaya ihtiyaç vardır.
Geleceğe baktığımızda gelişmiş topolojilere ve muhtemelen daha az yük kullanan ağlara ihtiyacımız var. Yeni şeylerden biri de yakın zamanda HPC Cray Slingshot için ticari Ethernet'i temel alan ancak çok daha kısa başlıklar kullanma seçeneği sunan yapı teknolojisi hakkında yayınlar oldu. Sonuç olarak genel gider azalır.
Her şey mümkün olduğu kadar basit tutulmalı, ancak daha basit olmamalıdır. Karmaşıklık ölçeklenebilirliğin düşmanıdır. Sadelik ve düzenli yapılar dostumuzdur. Bir yerde ölçeklendirme yapabiliyorsanız yapın. Ve genel olarak artık ağ teknolojilerine dahil olmak harika. Pek çok ilginç şey oluyor. Teşekkür ederim.
Kaynak: habr.com