Świat jest pełen protokołów sieciowych – sposobów komunikowania się sprzętu elektronicznego i komputerów. Szerokie zastosowanie tych protokołów można znaleźć w centrach danych, zwłaszcza wśród hiperskal, takich jak Google i Amazon.
Łączenie wszystkich serwerów w centrum danych jest operacją sieciową o dużej intensywności, a przez dziesięciolecia operatorzy ci używali najpopularniejszych protokołów komunikacyjnych, takich jak Ethernet, do fizycznego połączenia wszystkich tych serwerów i przełączników. (Tak, jest jeszcze wiele innych w użyciu, ale Ethernet stanowi większość tego, o czym mówimy). Ethernet istnieje już od dawna, ponieważ jest wysoce elastyczny, skalowalny i wszystkie inne -bledy. Ale jak wszystko w technologii, ma swoje ograniczenia.
Na początku tego roku Google zaprezentował swój nowy protokół sieciowy o nazwie Aquila , w którym wydaje się, że Google koncentruje się na jednym dużym ograniczeniu Ethernetu – opóźnieniu w sieci lub opóźnieniach spowodowanych ilością czasu potrzebnego do przenoszenia rzeczy w sieci Ethernet. Co prawda mierzymy opóźnienie w milionowych częściach sekundy (mikrosekundy, μs), ale w skali, o której mówimy, te opóźnienia sumują się.
Według słów Google :
„Obserwujemy nowy impas w centrach danych, gdzie postęp w przetwarzaniu rozproszonym jest coraz bardziej ograniczany przez brak przewidywalności wydajności i izolacji w wielodostępnych sieciach centrów danych. Różnica w wydajności od dwóch do trzech rzędów wielkości w zakresie tego, do czego dążą projektanci sieci i jakich aplikacji mogą oczekiwać i jakich programować, nie jest niczym niezwykłym, co poważnie ogranicza tempo innowacji w systemach rozproszonych opartych na klastrach wyższego poziomu”
Analizując ten dokument, wyłoniły się dla nas dwa pytania.
Po pierwsze, jakie aplikacje buduje Google, które są tak skomplikowane, że wymagają takiego rozwiązania. Google słynie z wysiłków na rzecz komercjalizacji rozwiązań przetwarzania rozproszonego. Wymyślili wiele najpopularniejszych narzędzi i koncepcji do dzielenia dużych, złożonych problemów obliczeniowych na małe, dyskretne zadania, które można wykonywać równolegle. Ale tutaj chcą to wszystko scentralizować.
Zamiast dyskretnych zadań, Google tworzy aplikacje, które są ściśle powiązane i współzależne, do tego stopnia, że muszą udostępniać dane w taki sposób, że mikrosekundy obniżają całość o „dwa do trzech rzędów wielkości”.
Odpowiedzią jest prawdopodobnie „sieci neuronowe AI” – co jest fantazyjnym określeniem mnożenia macierzy. Wąskim gardłem, z którym boryka się wiele systemów AI, jest to, że podczas obliczania ogromnych modeli różne etapy matematyki wpływają na siebie nawzajem – jedno obliczenie wymaga rozwiązania innego obliczenia, zanim będzie mogło zostać ukończone.
Zagłęb się w trudy startujących firm chipowych AI i wiele z nich założycieli tego rodzaju problemów. Google musi mieć modele tak duże, że te współzależności stają się wąskimi gardłami, które można rozwiązać tylko na skalę centrum danych. Prawdopodobnym kandydatem jest to, że Google potrzebuje czegoś takiego, aby trenować modele autonomicznej jazdy – które muszą uwzględniać ogromną liczbę współzależnych zmiennych. Na przykład, czy ten obiekt na Lidarze jest taki sam, jak to, co widzi kamera, jak daleko jest i ile czasu zajmie nam zderzenie z nim?
Możliwe też, że Google pracuje nad innymi bardzo intensywnymi obliczeniami. Artykuł wielokrotnie omawia High Performance Computing (HPC), który jest zwykle domeną superkomputerów symulujących pogodę i reakcje jądrowe. Warto zastanowić się nad tym, nad czym pracuje tutaj Google, ponieważ prawdopodobnie będzie to bardzo ważne gdzieś w dalszej kolejności.
Biorąc to pod uwagę, drugim czynnikiem, który wyróżniał się dla nas w tym artykule, jest poczucie skrajnej ironii.
Stwierdziliśmy, że ten akapit jest w szczególności bardzo zabawny (co zdecydowanie mówi więcej o naszym poczuciu humoru niż cokolwiek innego):
Kluczowe różnice w tych bardziej wyspecjalizowanych ustawieniach w stosunku do produkcyjnych środowisk centrów danych obejmują: i) możliwość przyjęcia wdrożeń z jednym dzierżawcą lub przynajmniej współdzielenia przestrzeni zamiast współdzielenia czasu; ii) mniejsze obawy związane z obsługą awarii; oraz iii) chęć przyjęcia niekompatybilnych wstecznie technologii sieciowych, w tym formatów przewodowych.
Chodzi o to, że Google chciał, aby Aquila zapewniała dedykowane ścieżki sieciowe dla pojedynczego użytkownika, zapewniała gwarantowane dostarczenie wiadomości i obsługiwała starsze protokoły komunikacyjne. Istnieje oczywiście szereg technologii sieciowych, które już to robią – nazywamy je przełączaniem obwodów i są one używane przez operatorów telekomunikacyjnych od ponad stu lat.
Wiemy, że Aquila jest zupełnie inna. Ale warto zastanowić się, ile technologii jest wahadłem. Przełączanie obwodów ustąpiło miejsca przełączaniu pakietów internetowych w wielu bolesnych, wyczerpujących dekadach transformacji. A teraz, gdy jesteśmy w punkcie, w którym protokoły internetowe zasilają prawie każdą sieć telekomunikacyjną, stan techniki powraca do dostarczania deterministycznego z dedykowanymi kanałami.
Nie chodzi o to, że Google jest regresywny, tylko o to, że technologia ma kompromisy, a różne aplikacje wymagają różnych rozwiązań. Pamiętaj, że następnym razem ktoś toczy świętą wojnę o taki czy inny protokół.
Google nie jest jedynym, który szuka czegoś takiego. Ogólnie rzecz biorąc, przełączanie pakietów, aw szczególności Internet, ma pewne poważne ograniczenia. Na świecie istnieją dziesiątki grup, które chcą rozwiązać te ograniczenia. Grupy te wahają się od pionierów Internetu, takich jak profesor Tim Berners-Lee i jego inicjatywa Solid, po nowe IP Huawei (nieco inne spojrzenie na to).
Projekty te mają oczywiście bardzo różne cele, ale wszystkie z nich borykają się z problemem pokonania zainstalowanej na całym świecie bazy. Natomiast Google nie chce zmieniać świata, tylko jego część.