Grid-server Vs. Shared Hosting

[patryk 451]

Uwazasz, ze nie ma shared / dedyk hostingu z odpowiednim supportem, stabilnoscia, jakoscia i wydajnoscia ?

I ze gridlayer z 256MB ram i CPU 2400 bedzie stabilniejszy, wydajniejszy niz dedyk z 4 x wiecej RAM i szybszym procesorem ?

 

Uważam, że znacznie łatwiej jest skorzystać z architektury GRID i korzystać z zasobów 12 maszyn nawet typu Athlon 2400 z 1 GB RAM (i mieć dane z nich zbackupowane na innych maszynach w Gridzie) niż stawiać samodzielnie powiedzmy 14 szybszych dedyków Athlon 3000 (7 na usługi, które by hostowało 12 2400'tek) i 7 na backup - żeby chociaż częsciowo zachować redunację z grida) i zarządzać tym.

 

Wiele jest przykładów ludzi na tym forum, którzy potworzyli serwisy typu "darmowe Przemo 4 you" i nagle z dnia na dzień po dołączeniu jakiegoś dużego forum dedyczek z Hetznera przestał wyrabiać. I co im pozostaje? Kupno nowego, czasochłonne przenoszenie danych, ew. 12h na wydzielenie osobnego node na MySQLa. W Gridzie po prostu dwa razy klikają i mają potrzebne zasoby.

 

Jeśli masz inną koncepcję na ten temat z chęcia wysłucham .

[Gość adamszendzielorz]

Uważam, że znacznie łatwiej jest skorzystać z architektury GRID i korzystać z zasobów 12 maszyn nawet typu Athlon 2400 z 1 GB RAM (i mieć dane z nich zbackupowane na innych maszynach w Gridzie) niż stawiać samodzielnie powiedzmy 14 szybszych dedyków Athlon 3000 (7 na usługi, które by hostowało 12 2400'tek) i 7 na backup - żeby chociaż częsciowo zachować redunację z grida) i zarządzać tym.

 

Daj mi przyklad kogos, kto potrzebuje mocy 14 serwerow dedykowanych i skorzysta z GRIDa, zamiast swoich autorskich rozwiazan ?

 

My tu mowimy o normalnych klientach na np. forum (moim zdaniem bardzo male i malo zasobozerne, ktore ruszy na kazdej wirtualce) o ktorym pisal w pierwszym poscie Piotr, nie o tworzeniu drugiego Onetu czy Allegro na "obcym" hostingu...

 

Znowu Twoj argument jest z kosmosu wziety.

pozdr.

[patryk 451]

Adam, to że Ty hostujesz stosunkowo małe strony na shared hostingu, nie znaczy, że nie istnieją wieksze i potrzebujące właśnie takich zasobów zarządzanych przez sprawne firmy i sprawnych administratorów..

[Gość adamszendzielorz]

Adam, to że Ty hostujesz stosunkowo małe strony na shared hostingu, nie znaczy, że nie istnieją wieksze i potrzebujące właśnie takich zasobów zarządzanych przez sprawne firmy i sprawnych administratorów..

 

... i tym sposobem zupelnie odbieglismy od tematu jakim jest, przypomne - Grid-server VS shared hosting.

pozdr.

[patryk 451]

Odbiegliśmy od tematu, bo dyskusja przebiega na poziomie "po co kupować Mercedesa Vito do przewożenia paczek skoro można zrobić 3 kursy Seicento VANem i przwewieźć to samo" - kwestia celu i potrzeb - a to już raczej temat do przemyślenia prywatnie dla każdego kto potrzebuje hostingu.

[cyberluk 0]

Ehh, nie dam rady cytować wszystkich kawałków postów, więc postaram sie pozbierać i napisać jakąś spójną całość.

 

Rozwiązania softwarowe mogą być wydajne, ale nie opensource nie oferuje w tej dziedzinie nic ciekawego. Jak już wspomniałem, jest LVS, który średnio się nadaje - warstwa 4 to za nisko. O kernelowym content-switchu też pisałem. Z poziomu kernela/systemu to wszystko. Zwykły round-robin na iptables - można zapomnieć.

Jeżeli chodzi o userland - jest fajny Pure Load Balancer - całkiem szybki, ale również nie daje nam możliwości prawdziwego content-switcha. On tylko balansuje połączenia pomiędzy maszyny produkcyjne.

Można użyć squida - zły model, stara technologia = porażka w wydajności.

Można użyć apache z mod_proxy, ale przecież chodzi nam o wydajność - po to budujemy grida.

Kilka dni temu z ciekawości patrzyłem na inne serwerki z możliwości reverse-proxy - też dałoby się coś posklejać.

Zawsze jednak będzie brakowało filtrowania w warstwie 7, sticky cookies, sticky sessions i kilku innych drobiazgów, które do działania _DOBREGO_ grida są potrzebne.

Jeżeli chodzi o różnicę pomiędzy gridem a shared hosting:

- redundancja - padnie jeden węzeł czy nawet kilka - nic się nie stanie. Adam o tym wspomniał. Wiąże się też z tym łatwość konserwacji systemu. Nie zostało jednak powiedziane, że bardzo łatwo jest zrobić upgrade maszyn do mocniejszych. Po prostu wymieniamy dany node i zmieniamy wagi na balancerze/content-switchu. I sukcesywnie możemy wymieniąc sobie te nody, aż wydajność klastra osiągnię zadowalającą wydajność.

- obsługa peaków - tutaj się zgodzę, że może nie jesteśmy stanami, ale takie peaki mogę się pojawić. Łatwiej jest je obsłużyć na takim gridzie, niż na pojedyńczej maszynie.

- kolejna sprawa, która nie została tutaj poruszona - optymalizacja wykorzystania procesora, a tym samym kosztów serwerów. Balansowanie samymi kontami per serwer wcale nie jest takie cacy. Przenoszenie klienta na inny serwer, przenoszenie danych itp itd. Tutaj takiego problemu nie ma. Klient raz założony jest sobie i już. Co więcej - zacznie potrzebować więcej mocy - płaci za tą moc i nic się specjalnego z nim nie dzieje.

Jeżeli chodzi o prównanie dedyk<>Grid. Dedyk jest jeden. Tutaj mamy/dostajemy całą infrastrukturę redundatną, administratora, ludzi którzy się znają itp itd. W przypadku dedyka masz dodatkowe koszty, chyba, że sam się znasz i wszystko zrobisz sam. O ile u nas takie podejście przejdzie, to w Stanach na 100% nie.

 

Teoretycznie taki grid dobrze zbudowany i dofinansowany jest w stanie zapewnić dostępność usługi na poziomie 99.9999%. Żaden pojedyńczy serwer nie zapewni takiej dostępności. To jest 31.5 sekundy downtime w ciągu roku. I da się to zrobić - sam brałem udział w projektowaniu klastra, który mógł mieć downtime 15 sekund w ciągu roku i to tylko 31 stycznia tuż przed 00:00.

 

Podumowując - grid jest bardziej odporny na awarie, lepiej wytrzymuje piki ruchu i jest alternatywą dla ludzi, którzy się nie znają, a usługi mają im działać.

[Gość adamszendzielorz]

Podumowując - grid jest bardziej odporny na awarie, lepiej wytrzymuje piki ruchu i jest alternatywą dla ludzi, którzy się nie znają, a usługi mają im działać.

 

Widze, ze masz spora wiedze nt. rozwiazan klastrowych

 

A powiedz mi, leciutko odbiegajac od tematu - jaka jest wydajnosc macierzy opartych np. o raptory na SATA II, w stosunku do normalnych "stacjonarnych", pojedynczych dyskow np scsi ?

pozdr.

[patryk 451]

cyberluk: gratuluję, że trafiłeś do Adama, bo mi się jak widać nie udało .

[Gość adamszendzielorz]

cyberluk: gratuluję, że trafiłeś do Adama, bo mi się jak widać nie udało .

 

Ja dalej uwazam ze placenie 100$ miesiecznie za utrzymanie skryptu pod forum o ktorym pisal Piotr jest chore, mozna zaplacic tyle za rok na shared hostingu i bedzie to dzialac bardzo podobnie

pozdr.

[cyberluk 0]

cyberluk: gratuluję, że trafiłeś do Adama, bo mi się jak widać nie udało .

 

Ja dalej uwazam ze placenie 100$ miesiecznie za utrzymanie skryptu pod forum o ktorym pisal Piotr jest chore, mozna zaplacic tyle za rok na shared hostingu i bedzie to dzialac bardzo podobnie

pozdr.

Bo to nie jest tak Popatrz na cenę konta w home.pl np. Popatrz na cenę takiego grida. Jeżeli cena będzie podobna, a ty masz hostować serwis firmowy, to co wybierzesz? Nie twierdzę, że home jest zły, chociaz kiedyś z ciekawości monitorowałem kilka pierdół i wiem, że wpadki się trafiają... Grid nie jest dla klienta szukającego taniego hostingu pod forum. To jest alternatywne rozwiązanie dla shared hostingu w podobnej cenie oferujące dużo większe możliwości i dużo większą stabilność. Oczywiście ktoś z dużym forum też może sobie kupić taką usługę gridową, jeżeli zależy mu na stabilności.

Należy jednak pamiętać o tym, że cena takiego grida nie może być wyższa od ceny shared hosting o takich samych parametrach. Różnica może tutaj być w opłacie za moc procesora. Bo to nie zostało podkreślone

 

(...)

Widze, ze masz spora wiedze nt. rozwiazan klastrowych

 

A powiedz mi, leciutko odbiegajac od tematu - jaka jest wydajnosc macierzy opartych np. o raptory na SATA II, w stosunku do normalnych "stacjonarnych", pojedynczych dyskow np scsi ?

pozdr.

 

Powiedzmy, że poprzedni mój pracodawca wdrażał kilka fajnych klastrów Ostatnio (eh, nie lubię się chwalić) dorobiłem się certa SUNa z SUNCluster. No i lubie się grzebać w hostingu Tak mi zostało ze "starych czasów". Odpoczynek po pracy to kombinowanie na moim małym labie w domu, co można by było zbudować.

 

Raptory 73GB przy ext3 na nich potrafią wyciagnąć około 300 tpsów przy Maildirach dość sporych. Dyski 7200 kończą się przy ~200 tpsach. SCSI od raptorów nie są dużo szybsze - mowa o 10k obr/min. Dostajesz za to mniejsze prawdopodobieństwo padu i stabilniejszy protokół. Od dwóch dni testuję sobie taką kombinację:

- SCSI 10k obr/min + XFS +external journal + Maildir

- IDE 7200 na journal

- PIV 2.4 GHz, ale ten na 533 magistrali i 1GB RAMu

- scheudler deadline

No i jak do tej pory jestem pod wrażeniem wydajności - do 400tpsów na SCSI i do 200 tpsów na journalu. Przeglądanie i praca na dużych maildirach jest po prostu rewelacyjna.

 

Inna sprawa, że pomimo wydajności raptorów nie wiem, czy skusiłbym się na macierz SATA. Pół roku temu padł mi NAS na kontrolerze 3ware 12 portowym. 8 dysków, RAID5, wysypał się jeden dysk, kontrolerowi odwaliło i cała macierz poszła się grzać... Został odzysk z backupu. Jak się później okazało, nie tylko mi to się przytrafiło Inna sprawa, że dysk padł po 6 miesiącach pracy... Jak widzisz ja się mam uzasadnioną awersję do SATA...

[Gość adamszendzielorz]

[...]

Inna sprawa, że pomimo wydajności raptorów nie wiem, czy skusiłbym się na macierz SATA. Pół roku temu padł mi NAS na kontrolerze 3ware 12 portowym. 8 dysków, RAID5, wysypał się jeden dysk, kontrolerowi odwaliło i cała macierz poszła się grzać... Został odzysk z backupu. Jak się później okazało, nie tylko mi to się przytrafiło Inna sprawa, że dysk padł po 6 miesiącach pracy... Jak widzisz ja się mam uzasadnioną awersję do SATA...

 

Ja wogole nie dotykam IDE / SATA jezeli chodzi o rozwiazania serwerowe, uzywam wylacznie SCSI. Pytam tylko dlatego, ze zaproponowales do tego klastra macierz z 16 dyskami SATA. Troche mnie to dziwi bo jestem pewien, ze w "standalone" serwerach taka ilosc dyskow SATA nie dalaby rady - przerost CPU nad wydajnoscia dyskow Ale nigdy nie mialem do czynienia z macierzami. Dlatego pytam bo nie wiem - moze maja jakies fajne mechanizmy keszujace i wydajnosc jest znaczaco wyzsza?

 

BTW. Po przejsciu na kernel 2.6 na kilku maszynach nie zauwazam absolutnie zadnych roznic w stosunku do kernela 2.4. Load maszyn wrecz lekko sie podniosl... Czasy generacji stron pozostaly na identycznym poziomie

pozdr.

[patryk 451]

adamszendzielorz: stabilność 2.6 z dobrym konfigiem w zastosowaniach shared hostingu jeśli chodzi o moje doświadczenia jest znacznie wyższa niż 2.4, zwłaszcza jeśli chodzi o sytuacje typu load 120 i potrzeba uspokojenia systemu. Przejrzałeś wszystkie nowe fancy opcje z menu config?

[cyberluk 0]

Ja wogole nie dotykam IDE / SATA jezeli chodzi o rozwiazania serwerowe, uzywam wylacznie SCSI. Pytam tylko dlatego, ze zaproponowales do tego klastra macierz z 16 dyskami SATA. Troche mnie to dziwi bo jestem pewien, ze w "standalone" serwerach taka ilosc dyskow SATA nie dalaby rady - przerost CPU nad wydajnoscia dyskow Ale nigdy nie mialem do czynienia z macierzami. Dlatego pytam bo nie wiem - moze maja jakies fajne mechanizmy keszujace i wydajnosc jest znaczaco wyzsza?

 

Duża macierz SATA na raptorach będzie miała taką samą wydajność, co macierz na dyskach 10k obr/min. Tutaj cała nadzieja na dobrą wydajność leży w kontrolerze. Promise wypuścił ostatnio 16 portów z własnym prockiem 500Mhz i spisuje się to pięknie jeżeli chodzi o wydajność.

 

BTW. Po przejsciu na kernel 2.6 na kilku maszynach nie zauwazam absolutnie zadnych roznic w stosunku do kernela 2.4. Load maszyn wrecz lekko sie podniosl... Czasy generacji stron pozostaly na identycznym poziomie

pozdr.

 

top - 15:48:11 up 30 days, 4:14, 0 users, load average: 2.43, 1.78, 1.01

Tasks: 577 total, 4 running, 573 sleeping, 0 stopped, 0 zombie

Cpu0 : 39.9%us, 7.6%sy, 0.0%ni, 43.6%id, 4.6%wa, 0.3%hi, 4.0%si, 0.0%st

Cpu1 : 38.9%us, 7.9%sy, 0.0%ni, 45.5%id, 7.3%wa, 0.0%hi, 0.3%si, 0.0%st

Cpu2 : 32.6%us, 4.7%sy, 0.0%ni, 57.1%id, 5.0%wa, 0.0%hi, 0.7%si, 0.0%st

Cpu3 : 37.4%us, 4.0%sy, 0.0%ni, 49.3%id, 8.6%wa, 0.0%hi, 0.7%si, 0.0%st

Mem: 3632700k total, 3260724k used, 371976k free, 32444k buffers

Swap: 979956k total, 60k used, 979896k free, 1361760k cached

 

To jest maszyna pod PHP FCGI. Różnica pomiędzy 2.4.x, a 2.6.x wynosi ~20% więcej reqeustów Czasy odpowiedzi pozostały podobne, maszyna lepiej reaguje na nagłe killowanie i tworzenie nowych PHPów - w sensie nie ma dziwnych skoków loadu i dziwnych zacięć.

[Piotr Mikołajski 0]

Ja dalej uwazam ze placenie 100$ miesiecznie za utrzymanie skryptu pod forum o ktorym pisal Piotr jest chore, mozna zaplacic tyle za rok na shared hostingu i bedzie to dzialac bardzo podobnie

Tak jak wczoraj rozmawialiśmy - generalnie masz rację, problem ze znalezieniem takiej usługi za Wielką lub Małą Kałużą. Albo jest SH w okolicy 5-6 dolarów miesięcznie, który jest nędzny pod każdym względem, albo są oferty po kilkadziesiąt dolców miesięcznie. Te pośrednie pasują tylko teoretycznie, bo np. większość angielskich firm chwalonych na WHT.com (czy brytyjskim odpowiedniku) ma śmiesznie małe parametry kont - 0,5-2GB miejsca na dysku.

 

Bo to nie jest tak Popatrz na cenę konta w home.pl np. Popatrz na cenę takiego grida. Jeżeli cena będzie podobna, a ty masz hostować serwis firmowy, to co wybierzesz? Nie twierdzę, że home jest zły, chociaz kiedyś z ciekawości monitorowałem kilka pierdół i wiem, że wpadki się trafiają... Grid nie jest dla klienta szukającego taniego hostingu pod forum. To jest alternatywne rozwiązanie dla shared hostingu w podobnej cenie oferujące dużo większe możliwości i dużo większą stabilność. Oczywiście ktoś z dużym forum też może sobie kupić taką usługę gridową, jeżeli zależy mu na stabilności.

Otóż to

Mnie oferta MT zainteresowała właśnie dlatego, że kosztuje tyle, co cywilizowany (niekoniecznie najtańszy) shared hosting, ale zapewnia spokój użytkownikowi. To z pewnością lekki overkill, ale z drugiej strony użytkownik ma gwarancję, że forum nie zacznie mulić i zawsze da się wywalić czy przeedytować post czy konto użyszkodnika. Wystarczy raz przeczytać taki komunikat przy kasowaniu konta spamera, żeby zacząć szukać lepszego hostingodawcy

 

Należy jednak pamiętać o tym, że cena takiego grida nie może być wyższa od ceny shared hosting o takich samych parametrach. Różnica może tutaj być w opłacie za moc procesora. Bo to nie zostało podkreślone

Zgadza się. Jeżeli będę miał za te same pieniądze GS oraz np. konto Pro w Home, to przy ich identycznych parametrach wybiorę Grida. W razie nagłego wzrostu popularności z Home mogą mnie wyrzucić, w GS dopłacę pod koniec miesiąca... albo i nie dopłacę. Mój serwis może być intensywnie oglądany przez godzinę dziennie, a przez pozostałe 23h może być nieodwiedzany - średnia wyjdzie mi poniżej normy i nie będę musiał dopłacać.

 

 

Dyskusji technicznej nie komentuję, wyłącznie czytam

[Gość adamszendzielorz]

To jest maszyna pod PHP FCGI. Różnica pomiędzy 2.4.x, a 2.6.x wynosi ~20% więcej reqeustów Czasy odpowiedzi pozostały podobne, maszyna lepiej reaguje na nagłe killowanie i tworzenie nowych PHPów - w sensie nie ma dziwnych skoków loadu i dziwnych zacięć.

 

U mnie roznicy nie bylo - skoki loadu w przypadku restartu apacza (wiec i procesow php fcgi) byly na takim samym poziomie Szkoda, ze w apaczu nie jest sensowniej rozwiazana kwestia uruchamiania FCGI z zewnatrz, nie startowane dynamicznie przez fcgi-pm. Niby jest fastcgiexternalserver ale jakies to takie nieudaczne W lighttpd to bajka..

 

Ale tym sie az tak nie przejmuje - moja maszynka rebutuje go tylko kiedy ktos cos zmieni w konfigu. Na "starych" maszynach (gdzie nie dochodza juz nowi klienci) czasem i 2-3 dni apacz chodzi bez restartu

 

BTW. czego uzywasz do benchmarkow ? Masz jakies konkretne softy ktore testuja "kompleksowo" maszynke ?

pozdr.

[Gość voytar]

U mnie roznicy nie bylo - skoki loadu w przypadku restartu apacza (wiec i procesow php fcgi) byly na takim samym poziomie Szkoda, ze w apaczu nie jest sensowniej rozwiazana kwestia uruchamiania FCGI z zewnatrz, nie startowane dynamicznie przez fcgi-pm. Niby jest fastcgiexternalserver ale jakies to takie nieudaczne W lighttpd to bajka..

Możesz rozwinąć i coś więcej o tym powiedzieć?

[Gość adamszendzielorz]

Możesz rozwinąć i coś więcej o tym powiedzieć?

 

Jasne, tylko o czym konkretnie ?

pozdr.

[cyberluk 0]

U mnie roznicy nie bylo - skoki loadu w przypadku restartu apacza (wiec i procesow php fcgi) byly na takim samym poziomie Szkoda, ze w apaczu nie jest sensowniej rozwiazana kwestia uruchamiania FCGI z zewnatrz, nie startowane dynamicznie przez fcgi-pm. Niby jest fastcgiexternalserver ale jakies to takie nieudaczne W lighttpd to bajka..

 

Ale tym sie az tak nie przejmuje - moja maszynka rebutuje go tylko kiedy ktos cos zmieni w konfigu. Na "starych" maszynach (gdzie nie dochodza juz nowi klienci) czasem i 2-3 dni apacz chodzi bez restartu

 

BTW. czego uzywasz do benchmarkow ? Masz jakies konkretne softy ktore testuja "kompleksowo" maszynke ?

pozdr.

 

Nie, benchmarki piszę pod konkretny przypadek. Staram się przy tym stworzyć jak najmniej szablonowy wzór testu. To jest część testów. Zanim zacznę je wykonywać, jadę zwykłymi standardowymi benchmarkami - bonnie, iozone, ab w zależności od tego nad optymalizacją którego komponentu pracuję. Dopiero po uzyskaniu dobrych i stabilnych wyników tworzę swój zestaw i poprawiam konfigurację. Jeszcze się nie zawiodłem

[Gość voytar]

Możesz rozwinąć i coś więcej o tym powiedzieć?

Jasne, tylko o czym konkretnie ?

pozdr.

Chodzi mi o to, co w startowaniu procesów fcgi przez Apache i FastcgiExternalServer jest nie tak jak trzeba.

[Gość Bartosz Gadzimski]

cyberluk -> ostatnio widziałem wiele rozwiązań różnych firm (nawet nie umiem nazwy firmy powtórzyć). Czy rzeczywiście taki grid musi kosztować aż tyle (pomijam oczywiście kwestię samych serwerów)?