Modern veri merkezlerinde, farklı izleme türlerinin kapsadığı yüzlerce aktif cihaz kuruludur. Ancak elinde mükemmel bir izleme bulunan ideal bir mühendis bile, bir ağ arızasına yalnızca birkaç dakika içinde doğru şekilde yanıt verebilecektir. Next Hop 2020 konferansındaki bir raporda, benzersiz bir özelliğe sahip olan bir veri merkezi ağ tasarımı metodolojisi sundum: veri merkezi kendisini milisaniyeler içinde iyileştirir. Daha doğrusu, mühendis sorunu sakin bir şekilde çözerken, hizmetler bunu fark etmiyor.
Birçok ağ mühendisi için bir veri merkezi ağı elbette ToR ile, raftaki bir anahtarla başlar. ToR'da genellikle iki tür bağlantı bulunur. Küçük olanlar sunuculara gidiyor, diğerleri - N kat daha fazlası var - birinci seviyenin omurgalarına, yani yukarı bağlantılara gidiyor. Uplink'ler genellikle eşit kabul edilir ve uplink'ler arasındaki trafik, proto, src_ip, dst_ip, src_port, dst_port'u içeren 5-tuple'dan gelen karma değerine göre dengelenir. Burada sürpriz yok.
Sonra, plan mimarisi neye benziyor? Birinci seviyedeki dikenler birbirine bağlı değildir, ancak süper dikenler aracılığıyla bağlanır. X harfi süper dikenlerden sorumlu olacak; neredeyse çapraz bağlantıya benziyor.
Ve diğer taraftan torilerin birinci seviyedeki tüm dikenlerle bağlantılı olduğu açıktır. Bu resimde önemli olan nedir? Rafın içinde etkileşimimiz varsa, o zaman etkileşim elbette ToR üzerinden gerçekleşir. Etkileşim modülün içinde meydana gelirse, etkileşim birinci seviye omurgalar aracılığıyla gerçekleşir. Eğer etkileşim modüller arası ise (burada ToR 1 ve ToR 2'de olduğu gibi), o zaman etkileşim hem birinci hem de ikinci seviyedeki omurgalardan geçecektir.
Teorik olarak böyle bir mimari kolayca ölçeklenebilir. Eğer liman kapasitemiz, veri merkezimizde boş alan ve önceden döşenen fiberimiz varsa, şerit sayısı her zaman arttırılabilir ve böylece sistemin genel kapasitesi arttırılabilir. Bunu kağıt üzerinde yapmak çok kolaydır. Hayatta da bu böyle olurdu. Ancak bugünün hikayesi bununla ilgili değil.
Doğru sonuçlara varılmasını istiyorum. Veri merkezinde birçok yolumuz var. Koşullu olarak bağımsızdırlar. Veri merkezi içindeki tek yol yalnızca ToR'da mümkündür. Modülün içinde şerit sayısına eşit yol sayısına sahibiz. Modüller arasındaki yolların sayısı, düzlem sayısı ile her düzlemdeki süper dikenlerin sayısının çarpımına eşittir. Konuyu daha açık hale getirmek, ölçeği anlamak için Yandex veri merkezlerinden biri için geçerli olan rakamları vereceğim.
Sekiz uçak var, her uçağın 32 süper dikeni var. Sonuç olarak, modülün içinde sekiz yol olduğu ve modüller arası etkileşimle zaten 256 tanesinin olduğu ortaya çıktı.
Yani Cookbook'u geliştiriyorsak, hataya dayanıklı, kendi kendini onaran veri merkezlerinin nasıl inşa edileceğini öğrenmeye çalışıyorsak, o zaman düzlemsel mimari doğru seçimdir. Ölçekleme problemini çözer ve teoride kolaydır. Birçok bağımsız yol var. Geriye şu soru kalıyor: Böyle bir mimari başarısızlıklardan nasıl kurtulur? Çeşitli başarısızlıklar var. Ve bunu şimdi tartışacağız.
Süper dikenlerimizden birinin “hastalanmasına” izin verin. Burada iki düzlemli mimariye geri döndüm. Örnek olarak bunlara bağlı kalacağız çünkü daha az hareketli parçayla neler olduğunu görmek daha kolay olacaktır. Bırakın X11 hastalansın. Bu, veri merkezlerinde yaşayan hizmetleri nasıl etkileyecek? Çoğu şey başarısızlığın gerçekte nasıl göründüğüne bağlıdır.
Arıza iyiyse, aynı BFD'nin otomasyon seviyesinde yakalanır, otomasyon sorunlu eklemleri mutlu bir şekilde yerleştirir ve sorunu izole eder, o zaman her şey yolundadır. Pek çok yolumuz var, trafik anında alternatif rotalara yönlendiriliyor ve hizmetler hiçbir şeyi fark etmeyecek. Bu iyi bir senaryo.
Kötü bir senaryo, sürekli kayıplarımızın olması ve otomasyonun sorunu fark etmemesidir. Bunun bir uygulamayı nasıl etkilediğini anlamak için TCP'nin nasıl çalıştığını tartışmaya biraz zaman ayırmamız gerekecek.
Umarım şu bilgiyle kimseyi şaşırtmam: TCP bir iletim onay protokolüdür. Yani, en basit durumda, gönderen iki paket gönderir ve bunlar hakkında kümülatif bir onay alır: "İki paket aldım."
Bundan sonra iki paket daha gönderecek ve durum tekrarlanacak. Bazı basitleştirmeler için şimdiden özür dilerim. Bu senaryo, pencere (uçuştaki paket sayısı) iki ise doğrudur. Elbette genel durumda bu durum mutlaka böyle değildir. Ancak pencere boyutu paket iletme bağlamını etkilemez.
Paket 3'ü kaybedersek ne olur? Bu durumda alıcı 1, 2 ve 4 numaralı paketleri alacaktır. Ve SACK seçeneğini kullanarak gönderene açıkça şunu söyleyecektir: "Biliyorsunuz üçü geldi ama ortası kayboldu." "Ack 2, SACK 4" diyor.
Şu anda sorunsuz bir şekilde gönderen, kaybolan paketin aynısını tekrarlar.
Ancak penceredeki son paket kaybolursa durum tamamen farklı görünecektir.
Alıcı ilk üç paketi alır ve öncelikle beklemeye başlar. Linux çekirdeğinin TCP yığınındaki bazı optimizasyonlar sayesinde, bayraklar bunun son paket veya benzeri bir şey olduğunu açıkça belirtmediği sürece, eşleştirilmiş bir paketi bekleyecektir. Gecikmeli ACK zaman aşımı süresi dolana kadar bekleyecek ve ardından ilk üç pakete bir bildirim gönderecektir. Ama şimdi gönderen bekleyecek. Dördüncü paketin kaybolup kaybolmadığını ya da gelmek üzere olup olmadığını bilmiyor. Ağı aşırı yüklememek için paketin kaybolduğuna dair açık bir göstergeyi veya RTO zaman aşımının sona ermesini beklemeye çalışacaktır.
RTO zaman aşımı nedir? Bu, TCP yığını tarafından hesaplanan maksimum RTT'dir ve bir miktar sabittir. Bunun nasıl bir sabit olduğunu şimdi tartışacağız.
Ama önemli olan şu ki, eğer yine şanssızsak ve dördüncü paket yine kaybolursa RTO iki katına çıkar. Yani her başarısız deneme, zaman aşımının iki katına çıkması anlamına gelir.
Şimdi bu tabanın neye eşit olduğunu görelim. Varsayılan olarak minimum RTO 200 ms'dir. Bu, veri paketleri için minimum RTO'dur. SYN paketleri için ise durum farklıdır, 1 saniye. Gördüğünüz gibi paketleri yeniden göndermeye yönelik ilk deneme bile veri merkezi içindeki RTT'den 100 kat daha uzun sürecektir.
Şimdi senaryomuza dönelim. Serviste neler oluyor? Hizmet paketleri kaybetmeye başlar. Hizmetin ilk başta şartlı olarak şanslı olmasına izin verin ve pencerenin ortasında bir şey kaybedin, ardından bir SACK alır ve kaybolan paketleri yeniden gönderir.
Ancak kötü şans tekrarlanırsa, o zaman bir RTO'muz olur. Burada önemli olan ne? Evet, ağımızda birçok yol var. Ancak belirli bir TCP bağlantısının TCP trafiği aynı bozuk yığından geçmeye devam edecektir. Bu sihirli X11'imiz kendi kendine sönmediği sürece paket kayıpları trafiğin problemsiz alanlara akmasına neden olmuyor. Paketi aynı bozuk yığın üzerinden teslim etmeye çalışıyoruz. Bu, kademeli bir arızaya yol açar: Bir veri merkezi, etkileşim halindeki uygulamalar kümesidir ve tüm bu uygulamaların TCP bağlantılarından bazıları bozulmaya başlar; çünkü süper omurga, veri merkezi içinde bulunan tüm uygulamaları etkiler. Söylendiği gibi: Eğer bir atı nallamazsanız, at topallar; at topalladı - rapor teslim edilmedi; rapor teslim edilmedi; savaşı kaybettik. Yalnızca burada, sorunun ortaya çıktığı andan hizmetlerin hissetmeye başladığı bozulma aşamasına kadar geçen süre saniye cinsindendir. Bu, kullanıcıların bir yerlerde bir şeyleri kaçırıyor olabileceği anlamına gelir.
Birbirini tamamlayan iki klasik çözüm var. Birincisi, pipet koymaya ve sorunu şu şekilde çözmeye çalışan hizmetler: “TCP yığınında bir şeyler ayarlayalım. Uygulama düzeyinde zaman aşımları veya dahili sağlık kontrolleri ile uzun ömürlü TCP oturumları yapalım.” Sorun şu ki, bu tür çözümler: a) hiç ölçeklenmiyor; b) çok kötü kontrol edilmiştir. Yani, hizmet TCP yığınını yanlışlıkla kendisini daha iyi hale getirecek şekilde yapılandırsa bile, ilk olarak, tüm uygulamalar ve tüm veri merkezleri için geçerli olma olasılığı düşüktür ve ikinci olarak, büyük olasılıkla bunun yapıldığını anlamayacaktır. doğru ve ne değil. Yani çalışıyor, ancak zayıf çalışıyor ve ölçeklenmiyor. Ve eğer bir ağ sorunu varsa, kim suçlanacak? Tabii ki NOC. NOC ne yapar?
Birçok hizmet, NOC çalışmalarında buna benzer bir şeyin gerçekleştiğine inanmaktadır. Ama dürüst olmak gerekirse, sadece bu değil.
NOC klasik şemada birçok izleme sisteminin geliştirilmesiyle ilgilenmektedir. Bunlar hem kara kutu hem de beyaz kutu izlemedir. Kara kutu omurga izleme örneği hakkında Alexander Klimenko son Next Hop'ta. Bu arada, bu izleme işe yarıyor. Ancak ideal izlemede bile bir zaman gecikmesi olacaktır. Genellikle bu birkaç dakikadır. Patlamanın ardından görevdeki mühendislerin çalışmasını bir kez daha kontrol etmek, sorunun yerini tespit etmek ve ardından sorunlu alanı söndürmek için zamana ihtiyacı var. Yani, kayıpların nerede olduğu hemen belli değilse, en iyi durumda sorunun tedavisi 5 dakika, en kötü durumda ise 20 dakika sürer. Tüm bu süre boyunca (5 veya 20 dakika) hizmetlerimizin sorun yaşamaya devam edeceği açık ve bu muhtemelen iyi bir şey değil.
Gerçekten ne almak istersiniz? Pek çok yolumuz var. Ve sorunlar tam da şanssız TCP akışlarının aynı rotayı kullanmaya devam etmesi nedeniyle ortaya çıkıyor. Tek bir TCP bağlantısında birden fazla rota kullanmamıza izin verecek bir şeye ihtiyacımız var. Görünüşe göre bir çözümümüz var. Çok yollu TCP denilen TCP yani çoklu yollar için TCP vardır. Doğru, tamamen farklı bir görev için geliştirildi - birkaç ağ cihazına sahip akıllı telefonlar için. Aktarımı en üst düzeye çıkarmak veya birincil/yedekleme modunu yapmak için uygulamaya şeffaf olarak birden fazla iş parçacığı (oturum) oluşturan ve arıza durumunda bunlar arasında geçiş yapmanızı sağlayan bir mekanizma geliştirildi. Veya dediğim gibi seriyi en üst düzeye çıkarın.
Ancak burada bir nüans var. Bunun ne olduğunu anlamak için iş parçacıklarının nasıl kurulduğuna bakmamız gerekecek.
Konular sırayla kurulur. İlk iş parçacığı ilk olarak yüklenir. Sonraki ileti dizileri daha sonra, söz konusu ileti dizisinde halihazırda üzerinde anlaşmaya varılmış olan çerez kullanılarak ayarlanır. Sorun da burada.
Sorun şu ki, eğer ilk iş parçacığı kendini oluşturamazsa, ikinci ve üçüncü iş parçacığı hiçbir zaman ortaya çıkmayacak. Yani çok yollu TCP, ilk akıştaki SYN paketinin kaybını çözmez. Ve eğer SYN kaybolursa, çok yollu TCP normal TCP'ye dönüşür. Bu, bir veri merkezi ortamında fabrikadaki kayıp sorununu çözmemize ve bir arıza durumunda birden fazla yolu kullanmayı öğrenmemize yardımcı olmayacağı anlamına gelir.
Bize ne yardımcı olabilir? Bazılarınız zaten başlıktan, ilerideki hikayemizdeki önemli bir alanın IPv6 akış etiketi başlık alanı olacağını tahmin etmiştir. Aslında bu v6'da görünen, v4'te olmayan, 20 bit yer kaplayan ve uzun süredir kullanımı konusunda tartışmalar olan bir alan. Bu çok ilginç - anlaşmazlıklar vardı, RFC'de bir şeyler düzeltildi ve aynı zamanda Linux çekirdeğinde hiçbir yerde belgelenmeyen bir uygulama ortaya çıktı.
Seni küçük bir araştırma için benimle gelmeye davet ediyorum. Son birkaç yılda Linux çekirdeğinde neler olup bittiğine bir göz atalım.
yıl 2014. Büyük ve saygın bir şirketten bir mühendis, akış etiketi değerinin soket karma değerine bağımlılığını Linux çekirdeğinin işlevselliğine ekler. Burada neyi düzeltmeye çalışıyorlardı? Bu, aşağıdaki sorunu tartışan RFC 6438 ile ilgilidir. Veri merkezinin içinde IPv4 genellikle IPv6 paketlerinde kapsüllenir, çünkü fabrikanın kendisi IPv6'dır, ancak IPv4'ün bir şekilde dışarıda verilmesi gerekir. Uzun süredir, TCP veya UDP'ye ulaşmak ve orada src_ports, dst_ports'u bulmak için iki IP başlığının altına bakamayan anahtarlarla ilgili sorunlar vardı. İlk iki IP başlığına bakarsanız karmanın neredeyse sabit olduğu ortaya çıktı. Bunu önlemek ve bu kapsüllenmiş trafiğin dengelenmesinin doğru şekilde çalışması için, 5'li kapsüllenmiş paketin karma değerinin akış etiketi alanının değerine eklenmesi önerildi. Diğer kapsülleme şemaları için de yaklaşık olarak aynı şey yapıldı, UDP için, GRE için, ikincisi GRE Anahtar alanını kullandı. Öyle ya da böyle, buradaki hedefler bellidir. Ve en azından o noktada faydalıydılar.
2015 yılında aynı saygın mühendisten yeni bir yama geliyor. O çok ilginç. Aşağıdakileri söylüyor - olumsuz bir yönlendirme olayı durumunda karmayı rastgele hale getireceğiz. Negatif yönlendirme olayı nedir? Bu daha önce bahsettiğimiz RTO yani pencerenin kuyruğunun kaybı gerçekten olumsuz bir olay. Doğru, bunun bu olduğunu tahmin etmek nispeten zor.
2016, yine büyük bir saygın şirket. Son koltuk değneklerini söker ve daha önce rastgele yaptığımız karmanın artık her SYN yeniden iletiminde ve her RTO zaman aşımından sonra değişmesini sağlar. Ve bu mektupta, ilk ve son kez, nihai hedef belirtiliyor: kayıplar veya kanal tıkanıklığı durumunda trafiğin yumuşak bir şekilde yeniden yönlendirilme ve birden fazla yol kullanma yeteneğine sahip olmasını sağlamak. Tabii bundan sonra pek çok yayın çıktı, bunları rahatlıkla bulabilirsiniz.
Hayır olmasına rağmen yapamazsınız çünkü bu konuyla ilgili tek bir yayın yok. Ama biliyoruz!
Ve ne yapıldığını tam olarak anlamadıysanız, şimdi size anlatacağım.
Ne yapıldı, Linux çekirdeğine hangi işlevler eklendi? txhash, her RTO olayından sonra rastgele bir değere dönüşür. Bu, yönlendirmenin çok olumsuz sonucudur. Karma bu txhash'a bağlıdır ve akış etiketi de skb karmasına bağlıdır. Burada fonksiyonlarla ilgili bazı hesaplamalar var, tüm detayları tek bir slayta sığdırmak mümkün değil. Merak eden varsa kernel kodunu inceleyip kontrol edebilir.
Burada önemli olan ne? Akış etiketi alanının değeri, her RTO'dan sonra rastgele bir sayıya dönüşür. Bu talihsiz TCP akışımızı nasıl etkiler?
SACK oluşursa hiçbir şey değişmez çünkü bilinen bir kayıp paketi yeniden göndermeye çalışıyoruz. Şimdiye kadar, çok iyi.
Ancak RTO durumunda ToR'daki hash fonksiyonuna akış etiketi eklediğimiz takdirde trafik farklı bir rota izleyebilir. Şerit sayısı arttıkça, belirli bir cihazdaki arızadan etkilenmeyen bir yol bulma şansı da artar.
Geriye bir sorun kalıyor: RTO. Elbette başka bir yol daha var ama bunda çok zaman kaybediliyor. 200 ms çok fazla. Bir saniye kesinlikle vahşidir. Daha önce hizmetlerin yapılandırıldığı zaman aşımlarından bahsetmiştim. Yani bir saniye, genellikle hizmet tarafından uygulama düzeyinde yapılandırılan bir zaman aşımıdır ve bu konuda hizmet nispeten doğru olacaktır. Üstelik tekrar ediyorum, modern bir veri merkezindeki gerçek RTT yaklaşık 1 milisaniyedir.
RTO zaman aşımları ile neler yapabilirsiniz? Veri paketlerinin kaybı durumunda RTO'dan sorumlu olan zaman aşımı, kullanıcı alanından nispeten kolay bir şekilde yapılandırılabilir: bir IP yardımcı programı vardır ve parametrelerinden biri aynı rto_min'i içerir. RTO'nun elbette küresel olarak değil, belirli önekler için ayarlanması gerektiği göz önüne alındığında, böyle bir mekanizma oldukça işe yarar görünüyor.
Doğru, SYN_RTO ile her şey biraz daha kötü. Doğal olarak çivilenmiştir. Çekirdeğin 1 saniyelik sabit bir değeri vardır, hepsi bu. Kullanıcı alanından oraya ulaşamazsınız. Sadece bir yol var.
eBPF kurtarmaya geliyor. Basitçe söylemek gerekirse, bunlar küçük C programlarıdır ve çok sayıda ayarı değiştirebileceğiniz çekirdek yığınının ve TCP yığınının yürütülmesinde farklı yerlerdeki kancalara yerleştirilebilirler. Genel olarak eBPF uzun vadeli bir trenddir. Onlarca yeni sistem parametresini kesmek ve IP yardımcı programını genişletmek yerine, hareket eBPF'ye doğru ilerliyor ve işlevselliğini genişletiyor. eBPF'yi kullanarak tıkanıklık kontrollerini ve diğer çeşitli TCP ayarlarını dinamik olarak değiştirebilirsiniz.
Ancak SYN_RTO değerlerini değiştirmek için kullanılabilmesi bizim için önemli. Üstelik halka açık bir örnek de var: . Burada ne yapıldı? Örnek işe yarıyor ama kendi içinde çok kaba. Burada veri merkezinin içinde ilk 44 biti karşılaştırdığımız varsayılır; eşleşirlerse veri merkezinin içindeyiz demektir. Ve bu durumda SYN_RTO timeout değerini 4ms olarak değiştiriyoruz. Aynı görev çok daha zarif bir şekilde yapılabilir. Ancak bu basit örnek bunun a) mümkün olduğunu gösteriyor; b) nispeten basit.
Zaten ne biliyoruz? Düzlem mimarisinin ölçeklendirmeye izin vermesi, ToR'da akış etiketini etkinleştirdiğimizde ve sorunlu alanların etrafından dolaşabilme yeteneğini kazandığımızda bizim için son derece yararlı oluyor. RTO ve SYN-RTO değerlerini düşürmenin en iyi yolu eBPF programlarını kullanmaktır. Soru hala ortada: Dengeleme için bir akış etiketi kullanmak güvenli midir? Ve burada bir nüans var.
Ağınızda herhangi bir yayında yaşayan bir hizmetinizin olduğunu varsayalım. Ne yazık ki, anycast'in ne olduğu hakkında ayrıntılı bilgi verecek vaktim yok ancak bu, aynı IP adresi üzerinden erişilebilen farklı fiziksel sunuculara sahip dağıtılmış bir hizmettir. Ve işte olası bir sorun: RTO olayı yalnızca trafik yapıdan geçtiğinde meydana gelemez. Ayrıca ToR arabellek düzeyinde de meydana gelebilir: bir incast olayı meydana geldiğinde, ana bilgisayar bir şey döktüğünde bile ana bilgisayarda meydana gelebilir. Bir RTO olayı meydana geldiğinde ve akış etiketini değiştirdiğinde. Bu durumda trafik başka bir anycast örneğine gidebilir. Bunun durum bilgisi olan bir anycast olduğunu, bir bağlantı durumu içerdiğini varsayalım; bu bir L3 Dengeleyici veya başka bir hizmet olabilir. O zaman bir sorun ortaya çıkıyor çünkü RTO'dan sonra TCP bağlantısı sunucuya ulaşıyor ve sunucu bu TCP bağlantısı hakkında hiçbir şey bilmiyor. Ve herhangi bir yayın sunucuları arasında durum paylaşımımız yoksa, bu tür trafik kesilecek ve TCP bağlantısı kesilecektir.
Burada ne yapabilirsin? Akış etiketi dengelemeyi etkinleştirdiğiniz kontrollü ortamınızda, herhangi bir yayın sunucularına erişirken akış etiketinin değerini kaydetmeniz gerekir. En kolay yol, bunu aynı eBPF programı aracılığıyla yapmaktır. Ancak burada çok önemli bir nokta var: Veri merkezi ağını işletmiyorsanız ancak telekom operatörüyseniz ne yapmalısınız? Bu sizin de sorununuz: Juniper ve Arista'nın belirli sürümlerinden başlayarak, karma işlevlerine varsayılan olarak bir akış etiketi ekliyorlar - açıkçası, benim için belirsiz bir nedenden dolayı. Bu, ağınızdan geçen kullanıcıların TCP bağlantılarını kesmenize neden olabilir. Bu yüzden yönlendirici ayarlarınızı buradan kontrol etmenizi önemle tavsiye ederim.
Öyle ya da böyle, bana öyle geliyor ki deneylere geçmeye hazırız.
ToR'da akış etiketini etkinleştirdiğimizde, artık ana bilgisayarlarda yaşayan eBPF aracısını hazırladığımızda, bir sonraki büyük arızayı beklememeye, kontrollü patlamalar yapmaya karar verdik. Dört bağlantıya sahip olan ToR'u aldık ve bunlardan birine düşüşler kurduk. Bir kural çizdiler ve dediler ki; şimdi tüm paketleri kaybediyorsun. Solda gördüğünüz gibi paket başına izlememiz var, bu da %75'e düştü, yani paketlerin %25'i kayboluyor. Sağ tarafta bu Şartnamenin arkasında yer alan hizmetlerin grafikleri bulunmaktadır. Temel olarak bunlar, rafın içindeki sunucularla arayüzlerin trafik grafikleridir. Gördüğünüz gibi daha da battılar. Neden %25 değil de bazı durumlarda 3-4 kat düştüler? TCP bağlantısı şanssızsa bozuk bağlantı noktasından ulaşmaya çalışmaya devam eder. Bu, DC içindeki hizmetin tipik davranışı nedeniyle daha da kötüleşir; bir kullanıcı isteği için, dahili hizmetlere yönelik N istek oluşturulur ve yanıt, tüm veri kaynakları yanıt verdiğinde veya uygulamada bir zaman aşımı oluştuğunda kullanıcıya gider. hala yapılandırılması gereken seviye. Yani her şey çok çok kötü.
Şimdi aynı deney, ancak akış etiketi değeri etkin durumda. Gördüğünüz gibi solda toplu izlememiz aynı %25 oranında düştü. Bu kesinlikle doğrudur, çünkü yeniden iletimler hakkında hiçbir şey bilmez, paketleri gönderir ve yalnızca teslim edilen ve kaybedilen paketlerin sayısını sayar.
Ve sağda servis programı var. Sorunlu bir eklemin etkisini burada bulamazsınız. Aynı milisaniyeler içinde trafik, sorunlu bölgeden, sorundan etkilenmeyen geri kalan üç bağlantıya doğru aktı. Kendi kendini iyileştiren bir ağımız var.
Bu benim son slaytım, özetleme zamanı. Artık kendi kendini onaran bir veri merkezi ağının nasıl oluşturulacağını bildiğinizi umuyorum. Linux çekirdek arşivini inceleyip orada özel yamalar aramanıza gerek kalmayacak, Flow etiketinin bu durumda sorunu çözdüğünü biliyorsunuz ancak bu mekanizmaya dikkatli yaklaşmanız gerekiyor. Ve şunu bir kez daha vurguluyorum ki eğer telekom operatörü iseniz, akış etiketini hash fonksiyonu olarak kullanmamalısınız, aksi takdirde kullanıcılarınızın oturumlarını aksatmış olursunuz.
Ağ mühendislerinin kavramsal bir değişime uğraması gerekiyor: Ağ, Şartnameyle ya da ağ cihazıyla değil, ana bilgisayarla başlıyor. Oldukça çarpıcı bir örnek, eBPF'yi hem RTO'yu değiştirmek hem de akış etiketini herhangi bir yayın hizmetlerine göre sabitlemek için nasıl kullandığımızdır.
Akış etiketi mekaniği, kontrollü idari segment içindeki diğer uygulamalar için kesinlikle uygundur. Bu, veri merkezleri arasındaki trafik olabilir veya bu tür mekanizmaları, giden trafiği yönetmek için özel bir şekilde kullanabilirsiniz. Ama bunu size bir dahaki sefere anlatacağım, umarım. İlginiz için çok teşekkür ederim.
Kaynak: habr.com