Numer telefonu : 13486085502
July 23, 2020
„Niezróżnicowane podnoszenie ciężarów”.W ten sposób Amazon Web Services scharakteryzował pracę zwykle wykonywaną przez działy IT w centrach danych przedsiębiorstw od czasu uruchomienia usługi chmury publicznej.
Przenieś się do chmury i „możesz wziąć ten rzadki zasób - swoich inżynierów programistów - i zamiast zmuszać ich do pracy nad niezróżnicowanym ciężkim podnoszeniem infrastruktury, możesz zająć się tym, co wyróżnia Twoją firmę” - zauważył dyrektor generalny AWS Andy Jassy podczas jego firma 2015 re: Invent keynotes.„A potem możesz wdrożyć aplikację w infrastrukturze na całym świecie”.
Na początku tego roku Dropbox - usługa przechowywania danych w chmurze oparta na AWS - uruchomiła swoją wysiłek zmierzający w innym kierunku.Przewidział czas, w którym nie będzie już mógł skalować swoich usług zgodnie z zapotrzebowaniem klientów, pomimo obietnic Jassy, że zasoby Amazona były w rzeczywistości nieskończone.Od lutego do października 2015 r. Dropbox z powodzeniem przeniósł 90 procent z szacunkowych 600 petabajtów danych swoich klientów do własnej sieci centrów danych o nazwie Magic Pocket.
„Od początku było dla nas jasne, że będziemy musieli budować wszystko od zera” - napisał wiceprezes ds. Infrastruktury Dropbox Akhil Gupta na swoim firmowym blogu w 2016 roku, „Ponieważ w społeczności open source nie ma nic, co sprawdziłoby się niezawodnie w naszej skali.Niewiele firm na świecie ma takie same wymagania dotyczące skali magazynowania jak my. ”
Takie stwierdzenia prowokowały niektórych do postrzegania odwrotnej migracji Dropbox jako pewnego rodzaju jednorazowego wydarzenia.W przeciwieństwie do codziennych przedsięwzięć w branży, takiej jak ropa naftowa, opieka zdrowotna czy ubezpieczenia, Dropbox był zainteresowany bezpośrednim wprowadzeniem zalet usług do własnego systemu.Jego wyprowadzenie z chmury nie było powszechnie postrzegane jako podróż, z której reszta świata IT mogłaby się czegoś nauczyć.
Pięć lat później wiele innych organizacji, w tym spoza branży IT, odkrywa, że istnieją ograniczenia dotyczące ich nieskończonej skalowalności w chmurze publicznej.Mogą istnieć uzasadnione powody, aby, mówiąc romantycznie, podróż do domu.Teraz podróż Magic Pocket zaczyna bardziej przypominać pionierską wyprawę.
„Dropbox opracował plan.Przyjrzeliśmy się, jakie są nasze możliwości, jakie spodziewaliśmy się naszego wzrostu ”- powiedział Latane Garetson, szef działu infrastruktury fizycznej centrum danych w Dropbox.Zgodnie ze zwyczajem zespół stworzył model planowania wydajności centrum danych.
Fakt, że Dropbox przeszedł przez to ćwiczenie, nie powinien być szokiem dla każdego, kto regularnie czyta witrynę taką jak DCK.Jednak dzisiejsze podejście firmy do planowania zdolności produkcyjnych może być zaskoczeniem.Zespół Garetsona działa w szczegółowych, krótkoterminowych oknach planowania - często sześć miesięcy, czasem trzy - znacznie krócej niż jest to powszechna praktyka.
„To swego rodzaju podejście wstecz” - przyznał.Nadal mają swoje roczne prognozy wzrostu, ale prognozy te są często aktualizowane przez cały rok, w oparciu o komunikację z zespołem programistów i przewidywane czasy realizacji („ile czasu zajmie zakup mocy i kiedy faktycznie możemy wylądować i udostępnić ją ”).
„Nadal współpracuje z naszą grupą oprogramowania i wewnętrznie upraszcza wszystko w Dropbox: mówi:„ Czego spodziewamy się w tym roku? ”i przygotuj prognozę modelu mocy, która jest zawsze aktualizowana - co miesiąc, co tydzień, co kwartał.Zespół centrum danych jest zawsze zintegrowany z tym procesem ”.
W wielu sklepach IT wdrożenie rozpoczyna się od nabycia lub zbudowania sprzętu, przygotowania go do pracy, wdrożenia, a następnie zintegrowania z klastrami usług i umieszczenia w nim oprogramowania.Podejście Dropbox działa w innym kierunku, powiedział nam Garetson.Zespół oprogramowania najpierw analizuje prognozy pojemności aktywnej i opracowuje szablon serwerów, których będą wymagały jego centra danych w różnych obszarach metropolitalnych.Ci programiści wykonują prace inżynieryjne związane z „papierkową robotą”, w tym konfiguracją usług i budową serwerów.
Podobnie jak klienci składający zamówienia w oknie drive-thru, te konfiguracje są następnie dostarczane zespołom sprzętowym w kolejności, a sprzęt jest produkowany zgodnie ze specyfikacjami zespołu programistycznego.Ponieważ zespół oprogramowania przygotował już plan konfiguracji, nowe serwery konfigurują się samoczynnie i nie wymagają żadnych czynności konfiguracyjnych ze strony inżynierów sprzętu.
- To dźwignie myWeź pod uwagę nasze czasy budowy ”- powiedział Garetson.„Zaczęliśmy w 2015 roku z sześciomiesięcznym czasem budowy.Przenieśliśmy to teraz na trzy miesiące… Nie bierzemy rocznej prognozy i nie wykorzystujemy tego.Przyjmujemy roczny i mamy plan, ale mamy również te krytyczne kamienie milowe, w których, jeśli prognoza się zmieni, możemy ją dostosować, ponieważ mamy tylko trzymiesięczny czas budowy ”.
Krótsze czasy kompilacji dla Dropbox są łatwiejsze do kontrolowania.Zamiast opóźniać kompilację z nieoczekiwanego powodu, można ją anulować, a zamiast niej uruchomić nowy plan, bez zakłóceń.Biorąc pod uwagę sposób, w jaki koordynatorzy mikrousług planują rozproszone komponenty oprogramowania - odcinając je, gdy nie odpowiadają - Dropbox odkrył, że może być bardziej elastyczny, jeśli chodzi o cele w zakresie wydajności, gdy trzyma się planu, który jest zgodny z harmonogramem przez cały czas, a nie częściowo lub całkowicie opóźnione.
Zespół uważnie monitoruje zmiany zapotrzebowania na fizyczną pojemność centrum danych w każdej ze swoich lokalizacji.Modelują dostępne zapasy w dowolnym momencie w bieżącym oknie i kiedy można udostępnić nowe zdolności produkcyjne.Korzystając z tej metody, Dropbox nigdy nie planuje celów dotyczących pojemności na następny rok.Podobnie jak budowanie masywnego muru po jednej cegle na raz, skupia się tylko na krótkoterminowym, planowaniu nie dłużej niż sześć miesięcy na raz.
Podobnie jak w większości centrów danych skoncentrowanych na pamięci masowej, gęstość szaf w obiektach Dropbox wzrosła w ciągu ostatnich pięciu lat.Umożliwiło to zmniejszenie całkowitego rozmiaru szafy, a jednocześnie zwiększenie pojemności magazynowej klientów w skali petabajtów.„Teraz możemy mieć trochę więcej fizycznej przestrzeni” - powiedział Garetson.„Tam, gdzie musielibyśmy zaplanować 100 szaf, teraz możemy zaplanować 30”.
Nie ma nic tak osobliwego w tej metodzie dynamicznego wzrostu i modelowania pojemności, że powinna pasować tylko do Dropbox lub innych firm zajmujących się przechowywaniem w chmurze.Do tej pory większość centrów danych w przedsiębiorstwach została zaprojektowana pod kątem miejsca i mocy przydzielonej do krytycznych usług i aplikacji.Dropbox oblicza, ile krytycznej usługi zapewni w postaci wektora wzrostu, którego tylko pierwsze sześć miesięcy będzie wykonalne.Gdyby organizacja była zdolna do ilościowego obliczania wyników swoich usług IT, tak jak robi to Dropbox, mogłaby opracować dla siebie podobny model planowania.W ten sposób może stwierdzić, że może kontrolować koszty, jednocześnie utrzymując swoje usługi lokalnie, unikając przełomu w przystępnej cenie usług chmurowych, z którym Dropbox nigdy nie miał do czynienia.
