Wielu nowych klientów, gdy zaczyna korzystać z CloudSigma, chce przetestować wydajność; często chcą porównać wyniki wydajności między serwerami chmurowymi a własną infrastrukturą i ma to sens. Zwykłe porównanie cen pod kątem zasobów nie mówi nam wszystkiego; to, co naprawdę się liczy, to wynik końcowy – ile kosztuje wykonanie konkretnego zadania obliczeniowego?
Dla każdego danego wymagania liczba zasobów potrzebnych do jego osiągnięcia może się znacznie różnić w zależności od chmury. Oznacza to, że samo porównywanie cen nie działa. Z drugiej strony, porównywanie samej wydajności w oderwaniu od innych czynników wcale nie jest lepsze. Sensowne porównania muszą łączyć zarówno cenę, jak i wydajność, aby obliczyć pewną miarę kosztu na jednostkę obliczeniową. W tym poście podzielę się kilkoma moimi przemyśleniami z testowania wydajności naszych serwerów chmurowych i innych. Przedstawię również kilka wskazówek, jak uzyskać przydatne wyniki i co one naprawdę oznaczają.
Ostrzeżenia
Wyjaśniając z góry, jestem dość sceptyczny wobec testów wydajnościowych w ogóle. Rzadko oferują one prawdziwy wgląd w rzeczywiste użytkowanie. Krótko mówiąc, nie ma prawdziwego zamiennika dla uruchomienia rzeczywistych aplikacji, z których zamierzasz korzystać na danej platformie. Jeśli możesz to osiągnąć przy rozsądnym nakładzie czasu, to nie ma lepszego rozwiązania niż takie ćwiczenie.
Kolejnym czynnikiem jest to, jak bardzo obciążony jest dostawca chmury. Możesz przetestować serwery chmurowe i uzyskać doskonałe wyniki. Mogą one jednak wynikać w dużej mierze z poziomu wykorzystania (lub jego braku) u tego konkretnego dostawcy. To może nie być pozytywny znak. Może to odzwierciedlać trudności w działaniu, utraconych klientów, wcześniejsze problemy z dostępnością i niezawodnością itp. Dlatego interpretując wyniki testów wydajnościowych, należy zawsze sprawdzić dostawcę chmury pod kątem wcześniejszych awarii i innych potencjalnych problemów.
Jako ostatnie ostrzeżenie, wydajność nie jest jedynym czynnikiem, który należy wziąć pod uwagę. Często niższa wydajność może odzwierciedlać bardziej solidną (i nadmiarową) architekturę sprzętową leżącą u jej podstaw. Dlatego zawsze ważne jest, aby bardzo dobrze rozumieć, na jakiej infrastrukturze zbudowana jest chmura. Dzięki temu można sprawiedliwie porównać wyniki, co pozwoli na podjęcie świadomej decyzji zakupowej.
Zdefiniuj problem
W dalszej części tego wpisu przedstawiam różne aspekty wydajności i sposoby na jak najlepszą interpretację wyników. Przed przystąpieniem do jakichkolwiek testów porównawczych ważne jest jednak określenie charakteru obliczeń, jakie zamierzasz prowadzić w chmurze; określi to względne znaczenie różnych metryk wydajności. Na przykład, jeśli chcesz umieścić serwer bazy danych, który będzie poddawany intensywnemu odczytowi, ale niewielkiemu zapisowi, powinieneś zwrócić uwagę na wydajność dysku w chmurze, a w szczególności na niesekwencyjny dostęp do odczytu.
Zanim więc zaczniesz testować wydajność serwerów chmurowych, określ, co uznałbyś za dobrą wydajność chmury. Powinieneś ustalić, które aspekty są kluczowe i mają nieproporcjonalnie duży wpływ na rzeczywistą wydajność Twoich obliczeń. Gdy będziesz mieć jasny obraz tej sytuacji, będziesz mógł zacząć przyglądać się testom wydajnościowym.
Wydajność obliczeniowa
Kiedy patrzymy na surową wydajność obliczeniową, mówimy o procesorze (CPU) i pamięci RAM. Różnice w wydajności na czysto obliczeniowym poziomie między chmurami nie są w rzeczywistości aż tak duże. Istnieją jednak pewne czynniki, które powodują realne różnice.
Zdecydowanie największym czynnikiem wpływającym na wydajność obliczeniową w chmurze jest współdzielenie zasobów. Chmury publiczne to środowiska wielodostępne. Pamięć RAM i pamięć masowa nie mogą być w rzeczywistości nadmiernie przydzielone (choć mogą być wyprzedane ponad stan), ale procesor (CPU) może być i jest. Poziomy współdzielenia różnią się znacznie, ale zasadniczo dostawcy chmur publicznych są w stanie sprzedać moc obliczeniową procesora fizycznego hosta w ilości przekraczającej 100%.
Niektórzy z największych dostawców stosują współczynniki współdzielenia procesora przekraczające trzykrotność. Oznacza to, że całkowita ‘sprzedana’ wydajność procesora wszystkich serwerów wirtualnych na tej samej maszynie fizycznej może być trzykrotnie większa niż jej rzeczywista wydajność. Robią to, ponieważ większość serwerów wirtualnych przez większość czasu nie wykorzystuje nawet w przybliżeniu 100% przydzielonego im procesora. Mimo to współczynniki współdzielenia bezpośrednio wpływają na testy wydajności serwerów chmurowych i ich rzeczywiste użytkowanie. Jeśli współdzielenie jest wysokie (tj. przy przydziale procesora przekraczającym 200%), wydajność serwera chmurowego ulegnie znacznemu pogorszeniu.
Mówiąc najprościej, jeśli obciążenie dowolnej maszyny fizycznej przekroczy 1 na rdzeń, zadania obliczeniowe są kolejkowane, a czas potrzebny tej maszynie wirtualnej na ukończenie pracy będzie dłuższy. Biorąc pod uwagę, że większość chmur nalicza opłaty na podstawie pojemności/godziny, ma to bezpośredni wpływ na koszty dla klientów tej chmury.
Innym ważnym czynnikiem wpływającym na wydajność obliczeniową jest liczba rdzeni procesora, do których maszyna wirtualna ma dostęp. Nie jest to istotne dla wszystkich aplikacji, ale wiele nowoczesnych aplikacji obsługuje wielowątkowość. W praktyce oznacza to, że aplikacja i/lub system operacyjny są w stanie rozłożyć zadania obliczeniowe na wiele rdzeni. Świetną wskazówką na poprawę wydajności obliczeń jest dopasowanie liczby wątków (tj. rdzeni), które aplikacja może obsłużyć, do liczby rdzeni, do których maszyna wirtualna ma dostęp.
Niestety, nie jest to możliwe w przypadku wielu chmur publicznych. Dzieje się tak, ponieważ ich platformy wirtualizacji nie obsługują wirtualizacji na poziomie rdzenia procesora. Innymi słowy, każdy rdzeń może być używany tylko przez jedną maszynę wirtualną naraz. W chmurach, które obsługują wirtualizację rdzeni procesora, warto poeksperymentować ze zmianą liczby rdzeni dla danej maszyny, zachowując jednocześnie tę samą całkowitą wydajność procesora.
Na przykład, jeśli masz maszynę 2GHz, możesz zobaczyć, jak podwojenie liczby używanych rdzeni z dwóch do czterech wpływa na Twoje testy wydajnościowe. Dzięki temu aplikacje uruchomione na tej maszynie wirtualnej będą mogły wykonywać zadania za pomocą czterech rdzeni jednocześnie. W naszym przypadku możesz ustawić liczbę rdzeni używanych przez maszynę wirtualną w zakładce ‘zaawansowane’ w oknie szczegółów serwera w konsoli internetowej. Pamiętaj tylko, aby zawsze sprawdzić, jaka jest standardowa wydajność rdzenia u dostawcy chmury, zanim ręcznie nadpiszesz liczbę używanych rdzeni. W naszym przypadku jest to 2.2GHz na rdzeń, ale różni się to w zależności od chmury.
Zalecałbym rozważenie użycia POV-RAY, CoreMark, Dhrystone lub Whetstone do testowania wydajności serwerów chmurowych.
Pamięć masowa: prawdziwy test wydajności serwerów chmurowych
Każda wydajność jest ograniczona przez najsłabsze ogniwo, w którym tworzy się wąskie gardło. Obecnie technologia poczyniła znaczne postępy w dziedzinie wirtualizacji w odniesieniu do wykorzystania procesora i pamięci RAM. Na przykład pojedyncza maszyna fizyczna może zostać zwirtualizowana i obsługiwać wiele serwerów chmurowych przy minimalnej stracie całkowitej zagregowanej wydajności. Niestety w przypadku pamięci masowej wciąż pozostaje wiele do zrobienia. Ostatecznym rezultatem jest to, że w większości przypadków wydajność serwerów wirtualnych w chmurze jest determinowana przez wydajność rozwiązania pamięci masowej tej chmury.
Krótko mówiąc, pamięć masowa jest obecnie czynnikiem ograniczającym wydajność większości zadań obliczeniowych w chmurze. Niezależnie od wyników, jakie POV-RAY i inne testy porównawcze mogą generować dla czystych zadań obliczeniowych, rzeczywistość jest taka, że szybkość, z jaką serwer wirtualny może pobierać i zapisywać dane na fizycznych dyskach pamięci masowej, określa obecnie rzeczywistą wydajność serwera chmurowego.
Mając to na uwadze, rzeczywiste różnice w wydajności obserwowane w chmurze, nawet w odniesieniu do zadań obliczeniowych, zwykle wynikają z różnic w wydajności pamięci masowej. Jak wspomniano wcześniej w tym wpisie, istnieją bardzo różne potrzeby klientów w zależności od zadania obliczeniowego. Nigdzie nie jest to bardziej widoczne niż w przypadku pamięci masowej. Czy potrzebujesz szybkiego dostępu do odczytu dużych sekwencyjnych bloków danych (takich jak media strumieniowe), czy też małych, rozproszonych informacji (być może w dużej bazie danych)? Czy musisz utrzymać intensywny dostęp do zapisu dla szybko zmieniających się danych, do których dostęp następuje okresowo w dużych seriach? Istnieje wiele scenariuszy i każdy z nich będzie działał inaczej na tej samej platformie.
Zasadniczo różnice w wydajności sprowadzają się do architektury. Te różnice w architekturze zazwyczaj wynikają z różnego stopnia niezawodności w odniesieniu do przechowywania danych, ich nadmiarowości, a co za tym idzie – prawdopodobieństwa ich bezpowrotnej utraty. Na wysokim poziomie chmury wykorzystują scentralizowane rozwiązania danych w postaci Storage Area Network (SAN) lub bardziej rozproszonych lokalnych rozwiązań pamięci masowej. W ich przypadku pamięć masowa znajduje się na każdej pojedynczej maszynie fizycznej.
Dobre sieci SAN mają ze swej natury wbudowany wysoki poziom nadmiarowości. Jednak wydajność spada, ponieważ dane muszą być przesyłane z sieci SAN przez sieć do procesora i pamięci RAM maszyny wirtualnej’ w celu wykonania zadań obliczeniowych. W rezultacie chmury oparte na sieci SAN mają zazwyczaj niższą wydajność w porównaniu z chmurami z lokalnymi, rozproszonymi rozwiązaniami pamięci masowej. Kolejną wadą sieci SAN jest to, że stanowi ona bardzo duży pojedynczy punkt awarii. Sieci SAN są niezwykle niezawodne. Jeśli jednak kiedykolwiek dojdzie do poważnej awarii (a tak się zdarzało), prawdopodobnie przyjdzie Ci się zmierzyć z bardzo dużą przerwą w działaniu i uszkodzeniem danych.
Większość dostawców chmury korzystających z sieci SAN nie stosuje w pełni nadmiarowych rozwiązań awaryjnych (fail-over) typu stosowanego w środowiskach korporacyjnych, głównie ze względów kosztowych. Ważne jest, aby zdać sobie sprawę, że nie każda sieć SAN jest’ sobie równa, i dowiedzieć się, jaki poziom nadmiarowości stosuje dany dostawca chmury w swoich sieciach SAN.
Chmury oparte na lokalnej pamięci masowej mają zazwyczaj dobrą wydajność dysków. Często jednak oferują one pamięć lokalną wyłącznie w formie nietrwałej. Nie jest’ to sprawiedliwe porównanie z trwałą pamięcią masową. Pamięć tymczasowa nie musi’ być odporna na awarie w taki sam sposób jak pamięć trwała. Aby uzyskać miarodajne wyniki, zawsze należy porównywać trwałą pamięć masową z trwałą pamięcią masową.
Przyglądając się chmurom z rozproszonymi lokalnymi rozwiązaniami pamięci masowej, musisz również wiedzieć, jaką posiadają nadmiarowość. Dyski twarde ulegają awariom ze znaczną częstotliwością, dlatego metoda przechowywania ma kluczowe znaczenie. Większość dostawców stosuje jakąś formę RAID , ale istnieją bardzo różne poziomy bezpieczeństwa. Na najniższym poziomie znajduje się RAID1, gdzie dwa dyski zasadniczo stanowią swoje lustrzane odbicie. Zwykle zapewnia to dobrą wydajność. Jednak w przypadku awarii jednego dysku, dopóki dysk zamienny nie skopiuje wszystkich danych ze starego dysku, dane są narażone na całkowitą utratę, jeśli ulegnie awarii drugi (mocno obciążony) dysk. Ponadto podczas odbudowy macierzy RAID1 wydajność dysków będzie prawdopodobnie znacznie niższa niż zwykle.
Wielu dostawców stosuje zatem RAID5 (odporny na awarię jednego dysku) lub RAID6 (odporny na awarię dwóch dysków). RAID6 oferuje zdecydowanie najbezpieczniejsze rozwiązanie dla lokalnej pamięci masowej, ale wiąże się z dużym spadkiem wydajności. Nasze podejście polega na stosowaniu RAID6, ale w połączeniu z najwyższej klasy sprzętowymi kontrolerami RAID. Posiadają one duże pamięci podręczne i podtrzymanie bateryjne. Kontrolery RAID, których używamy, są w rzeczywistości znacznie droższe niż całe macierze dyskowe. Dzięki temu możemy zapewnić wydajność porównywalną z o wiele mniej odpornymi konfiguracjami, oferując jednocześnie bardzo dużą siatkę bezpieczeństwa w postaci pamięci RAID6. Przeczytaj więcej o naszej infrastrukturze chmurowej , o której piszemy bardzo otwarcie.
Polecam użycie IOzone lub Bonnie++ do testów porównawczych wydajności dysków.
Zatem interpretując wyniki testów porównawczych pamięci masowej, upewnij się, że dysponujesz również następującymi informacjami:
- z jakiej architektury pamięci masowej korzysta chmura (lokalna, SAN, inna)?
- jakie środki przełączania awaryjnego i redundancji zostały wdrożone dla danych?
- czy pamięć masowa, którą testuję, jest tymczasowa czy trwała?
Zestawienie odpowiedzi na te trzy pytania z wynikami testów porównawczych da Ci dość dobry wgląd w rzeczywistą wydajność pamięci masowej.
Sieć
Wydajność sieci jest znacznie prostsza do określenia i zmierzenia niż wydajność obliczeniowa i dyskowa. Wydajność sieci ma dwa kluczowe aspekty: opóźnienie i przepustowość.
W zależności od Twoich potrzeb, opóźnienie sieci używanej przez dostawcę chmury może, ale nie musi być istotne. Jeśli korzystasz z chmury do operacji w dużej mierze autonomicznych, mało prawdopodobne jest, aby opóźnienie było priorytetem. Jeśli jednak uruchamiasz aplikacje działające w czasie rzeczywistym, które wchodzą w interakcję ze światem zewnętrznym poza chmurą, opóźnienie będzie kluczowym czynnikiem determinującym wydajność.
Zazwyczaj zdecydowana większość opóźnień wynika z samej odległości fizycznej. Na przykład większość opóźnień między Londynem a San Francisco to w rzeczywistości czas potrzebny na pokonanie tej odległości przez światło. Różnice w opóźnieniach wynikają z różnej efektywności wybranej trasy. Jest to aspekt, który różni się w zależności od chmury. Efektywność trasy jest bezpośrednim rezultatem dostawców sieci, z którymi chmura ma bezpośrednie połączenia. Dzieje się tak poprzez pobieranie od nich łączności IP lub poprzez peering. Analizując opóźnienia, możesz po prostu spingować swój serwer w chmurze i określić jego wydajność. Ważne jest jednak, aby określić wydajność między rzeczywistymi użytkownikami końcowymi a Twoim serwerem w chmurze.
Jeśli większość Twoich użytkowników znajduje się w jednym obszarze geograficznym lub dostęp będzie odbywał się głównie z głównej siedziby Twojej firmy, ważne jest, aby przetestować wydajność z tych lokalizacji. Usługi komercyjne, takie jak Pingdom oferują opłacalny sposób określania opóźnień z dużej liczby ogólnych lokalizacji jednocześnie na całym świecie.
Rzeczywista przepustowość, jaką może osiągnąć Twój serwer w chmurze, jest również bardzo ważna. W przeciwieństwie do bardziej tradycyjnych rozwiązań hostingowych, dostawcy chmury zazwyczaj pobierają opłaty w odniesieniu do łącznego wolumenu transferu danych. Innymi słowy, nie zależy to od czasu, jak w przypadku rozliczeń za Mbit, co zapewnia stały poziom łączności 24/7. Mimo to wielu dostawców chmury będzie ‘dławić’ przepustowość dowolnego serwera wirtualnego. Będzie to niewidoczne dla użytkownika, dopóki nie napotka on tej bariery. Jeśli Twój profil przepustowości charakteryzuje się dużymi skokami, może to być ważny czynnik wydajnościowy, który należy wziąć pod uwagę.
Aby przetestować rzeczywistą przepustowość serwera w chmurze, ważne jest, aby spróbować pobrać dane na serwer w chmurze ze źródła, które nie ogranicza prędkości transferu po swojej stronie. Często uważam, że świetnym sposobem na określenie dostępnej prędkości jest pobranie dużego pliku od dużego dostawcy, takiego jak Microsoft, Ubuntu lub, co jeszcze lepsze, poprzez aktualizację systemu operacyjnego. Wiąże się to zazwyczaj z jednoczesnym pobieraniem wielu różnych plików z różnych lokalizacji. Da Ci to całkiem dobry obraz prędkości Twojego połączenia.
Często pobieram Fedora live CD z ich głównej witryny jako test standardowy, ale powinieneś przynajmniej poeksperymentować z kilkoma różnymi plikami i lokalizacjami. Jeśli zależy Ci na posiadaniu własnej, bardzo szybkiej sieci korporacyjnej, możesz zamiast tego pobrać plik ze swojego serwera w chmurze do własnej sieci w ramach testu.
Teraz ponownie uwzględnij ceny przy ocenie wyników
Korzystając z powyższych metod, powinieneś być w stanie dobrze ocenić, jak radzą sobie poszczególni dostawcy serwerów w chmurze. Ponadto powinieneś wiedzieć, na których aspektach się skupić, jako najważniejszych dla Twoich konkretnych potrzeb.
Ostatnim krokiem jest dodanie wymiaru cenowego do wyników testów porównawczych. Nie ma na to gotowego wzoru. Zależy to od względnej wydajności różnych aspektów opisanych powyżej, a to Ty je określasz. Jeśli jedna chmura zapewnia o 40% lepszą wydajność (według Twojej oceny), ale jest tylko o 30% droższa, to oczywiście wygląda to atrakcyjnie. Podobnie, jeśli masz duże zapotrzebowanie na przepustowość, niższa wydajność obliczeniowa może zostać zrekompensowana przez konkurencyjny plan cenowy transferu danych. Kluczem do podjęcia właściwej decyzji jest uwzględnienie wszystkich tych różnych czynników.
Na koniec, testy porównawcze powinny być częścią większego procesu określania, które serwery chmurowe są dla Ciebie odpowiednie. Powinien on obejmować również inne aspekty. Mogą to być na przykład umowy o gwarantowanym poziomie usług (SLA), kwestie uzależnienia od dostawcy lub danych, lokalizacja fizyczna oraz jurysdykcja prawna. Zebranie wszystkich tych aspektów pozwoli Ci dokonać właściwego wyboru dostawcy usług chmurowych.
Komentarze
Brak komentarzy. Bądź pierwszy.