Oktawave - problemy 06.2016

[ArrChi 0]

Witam,

 

Posiadamy kilka serwerów w polskiej chmurze Oktawave. Jak dotąd był spokój, ale od kilku tygodni chmura wciąż zaskakuje awariami, przerwami w dostępie do danych, dysków a jej strona statusowa jest aż czerwono-żółta od statusów.

 

Czy ktoś otrzymał od chmury jakieś lepsze wyjaśnienie niż lakoniczne "przepraszamy za niedogodności" ?

[Desavil 88]

Witaj!

Dzisiejszej nocy, tj. z 22 na 23 czerwca, w godzinach pomiędzy 02:00 a 04:00, może wystąpić ryzyko chwilowej utraty dostępu do dysków, podwyższonych czasów dostępu lub wyłączenia bądź restartu niektórych OCI. W tym czasie zalecamy wyłączenie maszyn.

Powyższa przerwa związana jest z koniecznością wymiany kluczowych urządzeń odpowiadających za sieć Infiniband obsługującą dostęp do dysków w subregionach PL-002 i PL-003. Decyzja o wymianie podjęta została w związku z dzisiejszą niestabilnością infrastruktury w subregionie PL-003.

Wspomniane prace mają na celu zapewnienie stabilności usług.

 

Edytowano Czerwiec 22, 2016 przez Desavil (zobacz historię edycji)

[ArrChi 0]

Tak tez dostalem takie powiadomienie,pytalem o cos innego. Ostatnio bardzo czesto i duzo tych przerw i restartow OCI. Pytalem czy ktos ma jakies blizsze informacje co sie dzieje i kiedy Okta upora sie z tymi problemami.

Edytowano Czerwiec 22, 2016 przez ArrChi (zobacz historię edycji)

[przemon 35]

Jestem w oktawave od początku.

Mieli faktycznie kilka problemów (łącza, storage,)

Mam wirtualki we wszystkich subregionach.

 

PL-001 - ostatnio był lag ze 2-3 tygodnie temuv na między instancją a storage

PL-002 - z rok temu był ostatnio jakiś problem (restart instancji)

PL-003 - w styczniu był ostatnio problem ze storage

 

 

I potwierdzam, ze storage najczęściej jest lipa.

 

Ogólnie to problem się zaczyna jak kleisz większy storage LVM Tier-1 i masz na nim ruch (ja mam akurat taki jeden hostingowy)

Bo jak jeden z węzłów nagle ma await na parę sekund (zdarza się)to load od razu rośnie w kosmos i kernel sypie błędami.

Czasem się to kończy restartem serwera, sprawdzaniem spójności danych etc.

 

Dla węzłów do 300GB takiego problemu nie zaobserwowałem. Prawdopodobnie dlatego, że mają tych przestrzeni storage kilka i jak masz 4 węzły po 300GB to jest większa szansa że któryś złapie laga. Nie wiem, nie mam takich informacji od nich. Przy ostatnim problemie dostałem odpowiedź, że u nich wszystko grało a wg mnie nie do końca.

 

Zastanawiam się nad migracją tego hostingowego na dedyka. Bo po 1 wyjdzie taniej, po drugie będę miał własną przestrzeń storage.

 

Edytowano Czerwiec 22, 2016 przez przemon (zobacz historię edycji)

[Misiek08 285]

@przemon - zdecydowanie zmigruj to, bo u nich nie ma na żywo backupu instancji w innym miejscu DC, więc jak ogarniesz na dedyku to taniej i stabilniej. A skoro hostingowy, to za transfer płacisz też trochę, więc ogarniesz 2 dedyki i masz spokój.

Każda chmura jest fajna pod zastosowania chmurowe, ale nie pod typowo np. hosting stron z dużą ilością danych, czy storage. Pod bloga zajmującego 1G, na którego wchodzi 500tys. ludzi dziennie to ma sens, ale pod nic co zajmuje miejsce na dysku i używa dużo transferu.

Co do stabilności to rzeczywiście były kłopoty ze storage, ale na szczęście wiemo nich tylko z monitoringu, bo mam teraz 4-5 instancji i wszystko trzymają w RAMie, a na dysk leci dump okresowo (który i tak najpierw trafia w RAM )

[Maciej Kuźniar 1]

Cześć,

 

Generalnie macie racje, faktycznie ostatnie tygodnie były ciężkie głównie z powodu tego że technologia której do tej pory używaliśmy do budowy sieci storage (Infiniband) przy obecnej już wielkości infrastruktury przestała działać stabilnie. Core tej sieci dział w oparciu o SRP którego rozwój zarówno przez Mellanoxa i jak i vmware'a został (być może nieoficjalnie) zarzucony. Mieliśmy dwie opcje tj. iser albo FC. Iser na razie nie wygląda najlepiej wobec czego podjęliśmy decyzję o całkowitej migracji na SAN FC i to się właśnie stało dzisiaj tj. 23.06.216 został wymieniony cały rdzeń sieci, agregacje, switche brzegowe oraz same karty HBA/HCA we wszystkich serwerach Oktawave - to była cholernie trudna operacja bo tego jest już naprawdę dużo, szczególnie że chcielibyśmy utrzymać większość usług online - co w dużej części się udało jakkolwiek skończyliśmy dopiero o 7 rano a nie o 4 zgodnie z planem.

 

Podsumowując, od dzisiaj Oktawave nie działa już na Infini, jedziemy na FC 8/16Gbps (zależnie od regionu). To oznacza mamy nadzieję dużo większą stabilność w dostępie do OVS'ów przy trochę większym latency (Infiniband to rząd mikrosekund, FC to milisekundy). Z punktu widzenia klienta lepiej mieć stałe 5-10ms niż zazwyczaj 0,5ms w skokach do tysiąca.

 

W ciągu kilku dni pojawią się też nowe subregiony oparte o najnowsze Intele, tak więc warto będzie rozważyć migrację do nich.

 

W każdym razie - mogę tylko przeprosić że nie zdecydowaliśmy się na ten krok (związany z wymianą sieci) wcześniej i pokornie przyznać że nie nadążaliśmy ostatnio za skalą ale wyciągnęliśmy już z tego stosowne wnioski.

 

Pozdrawiam,

Maciej Kuźniar.

 

 

 

[przemon 35]

Dziękujemy za wyjaśnienia. Szkoda faktycznie że tak późno.

Sprawdziłem i na chwilę obecną gołym okiem widać że jest lepiej.

Testy też to potwierdzają, tier-1 chodzi teraz praktycznie jak na początku w 2012/2013r

Zniknął nawet "lag" przy logowaniu ssh (oczekiwanie na prompt)

 

dd bs=1M count=4096 if=/dev/zero of=test conv=fdatasync
4096+0 przeczytanych recordów
4096+0 zapisanych recordów
skopiowane 4294967296 bajtów (4,3 GB), 11,2123 s, 383 MB/s

 

i to wynik przy jednym węźle, przy lvm 4x300GB wiadomo jest wolniej (190MB/s)

Wcześniej to było analogicznie 70-110MB/s i 45-60MB/s (były czasem okresy kiedy chodziło szybciej ale potem wracała zamuła). Zobaczymy jak to będzie wyglądało na przestrzeni miesiąca.

Oby tak samo, bo nie chce mi się przeprowadzać/migrować, a już się za dedykiem rozglądałem.

 

 

 

Edytowano Czerwiec 23, 2016 przez przemon (zobacz historię edycji)

[Misiek08 285]

Dziękujemy za wyjaśnienia. Szkoda faktycznie że tak późno.

Sprawdziłem i na chwilę obecną gołym okiem widać że jest lepiej.

Testy też to potwierdzają, tier-1 chodzi teraz praktycznie jak na początku w 2012/2013r

Zniknął nawet "lag" przy logowaniu ssh (oczekiwanie na prompt)

 

dd bs=1M count=4096 if=/dev/zero of=test conv=fdatasync

4096+0 przeczytanych recordów

4096+0 zapisanych recordów

skopiowane 4294967296 bajtów (4,3 GB), 11,2123 s, 383 MB/s

 

 

i to wynik przy jednym węźle, przy lvm 4x300GB wiadomo jest wolniej (190MB/s)

Wcześniej to było analogicznie 70-110MB/s i 45-60MB/s (były czasem okresy kiedy chodziło szybciej ale potem wracała zamuła). Zobaczymy jak to będzie wyglądało na przestrzeni miesiąca.

Oby tak samo, bo nie chce mi się przeprowadzać/migrować, a już się za dedykiem rozglądałem.

 

 

 

 

Będzie do 20% wolniej, ale nie gorzej. Tak było w innej chmurze jak odpalili storage. Nie wiem czy to kwestia rurek, ale po prostu z doświadczenia tyle Ci doradzę

 

[Maciej Kuźniar 1]

@Przemon - tak naprawdę to jest wieczna rozbudowa i wszystko zależy od jej tempa. Jeśli z jakiegoś powodu zwolnimy z rozbudową to dzieje się tak właśnie jak zaobserwowałeś. Ciężko tutaj o moment złapania oddechu, dokładasz kilkaset dysków i już widzisz że jak nie zamówisz kolejnych to za 3 miesiące będzie słabo. I tak w kółko :-) Architektura za tym wszystkim musi nadążać bo ciągle zmieniają się warunki brzegowe. Na tym polega cała trudność chmury - klienci dostają dużą elastyczność, ale my bierzemy to na siebie a pod spodem jednak operujemy na prawie normalnych gratach - no tyle że to już nasz problem W sumie to chyba definicja dlaczego dedyk może być tańszy.

 

@Misiek08 - no tak, wahania zawsze będą, pytanie czy mają znaczenie. Tj. powiedzmy 20% od 350 MB/s przy odczytach to 280MB/s - nadal wydaje sie good enough :-) Problem jest jeśli to spada poniżej jakiejś konkretnej brzegowej wartości kiedy zaczyna przeszkadzać.

 

 

 

[Misiek08 285]

@Misiek08 - no tak, wahania zawsze będą, pytanie czy mają znaczenie. Tj. powiedzmy 20% od 350 MB/s przy odczytach to 280MB/s - nadal wydaje sie good enough :-) Problem jest jeśli to spada poniżej jakiejś konkretnej brzegowej wartości kiedy zaczyna przeszkadzać.

 

 

 

 

W sumie nie wyraziłem konkretniej opinii, ale nie miałem zamiaru w żaden sposób negować Oktawave. Te 20% to dla mnie jakby "wkalkulowana strata" i piszę, żeby ktoś nie płakał, że "było 350 to ucięli, bo było zbyt pięknie". Osobiście dla mnie 250MB/s, czy nawet 200MB/s, ale stałe i przede wszystkim - ze stałym, nawet dość wysokim czasem dostępu. 5-10ms to moim zdaniem trochę dużo, ale jak będzie potrzebne mniej, to po prostu inna usługa i tyle Jak się utrzyma poniżej 5ms to każdy powinien być zadowolony, bo takie czasy mają inne chmury (niektóre mają te 0.5-1ms i to jest idealnie).