Pytanie o wybór technologii

[lugu 0]

Witajcie!

Mam pewien problem do przemyślenia i ze względu na moje niewielkie doświadczenie w temacie, zwracam się do Was z prośbą o kilka ewentualnych porad.

Pracuję dla człowieka, który ma władzę nad kilkoma przedsięwzięciami posiadającymi własne strony www. Generalnie jest tak, że przeważnie każde z tych wspomnianych przedsięwzięć jest prowadzone przez osobną firmę/stowarzyszenie/fundację itp. Strony internetowe - jak możecie się domyślić - wiszą na różnych hostingach.

Ostatnio pojawił się pomysł powołania wydzielonej jednostki, która będzie się centralnie zajmowała hostingiem wszystkich stron poszczególnych przedsięwzięć. Dodatkowo szefostwo zastanawia się nad rozpoczęciem (w późniejszym terminie) pewnego rodzaju działalności hostingowej (raczej na niewielką skalę) dla swoich swoich sympatyków/klientów. Wychodzi więc na to, że każda jednostka (własna, jak i "klienta") musi być obsługiwana właściwie jak w klasycznej firmie hostingowej. Ma mieć swój własny panel, ma być podliczana przez system bilingowy itp.

Na początek w grę wchodziłoby 7-9 stron własnych, notujących od kilkudziesięciu do kilkudziesięciu tysięcy uu miesięcznie.

Z marszu wybiłem szefostwu pomysły z własną serwerownią, jak i z kolokacją własnego sprzętu w którymś z centrów danych (oczywiście ze względu na koszty, ale i też brak zaplecza informatycznego - czytaj: administratorów z dostatecznym doświadczeniem).

W grze pozostaje więc któraś o opcji z dzierżawieniem powierzchni hostingowej pod wspomniane przedsięwzięcie. I tu moje właściwe pytanie do doświadczonych kolegów/koleżanek: które z dostępnych rozwiązań byłoby najodpowiedniejsze dla rozpoczęcia opisanej działalności, z możliwie minimalnym ryzykiem poniesienia znaczących strat finansowych i jednocześnie na odpowiednio wysokim poziomie? Jakieś dobre konto resellerskie (tylko white label), serwer VPS, serwer dedykowany? A może rozwiązaniem byłoby konto w jakiejś chmurze (przykładowo Oktawave) ze swoją skalowalnością i rozliczaniem godzinowym?

Dodatkowe informacje. Prawdopodobnie na początku (przynajmniej do etapu z hostowaniem stron własnych) musiałbym zajmować się wszystkim osobiście. Jestem informatykiem z wykształcenia, ale nie mam dużego doświadczenia w administrowaniu systemami. Nie boję się linuksa (używam w domu Gentoo, administruję też niewielkim, wewnętrznym serwerkiem w jednej z jednostek - również na Gentoo), jak trzeba to także poprogramuję. Lubię się uczyć i szybko mi to idzie. Dam radę?

Szefostwu zależy też na znacznej autonomii - czyli nie podleganiu przykładowo pod regulaminy przyszłego hostingodawcy dotyczące ilości wysyłanych maili, brak telefonów od hostingodawcy o wysyłaniu spamu itp. Wszystkie tego typu problemy chcielibyśmy załatwiać samodzielnie i na własny rachunek. Rozumiem, że ten punkt eliminuje raczej konto resellerskie, mam rację?

[Westbam 64]

Raczej ciężko będzie Ci taki hosting znaleźć - każdy ma jakieś limity.. Jedynym rozwiązaniem może być serwerek w OVH pod strony WWW (ale dodatkowo nie mam pojecia jaki ruch masz tych 9-ciu stron, na jakim skrypcie są prowadzone)... Jeśli ruch duży polecałbym zastanowić się nad serwerem dedykowanym

 

Może zastanów się nad:

http://www.ovh.pl/serwery_dedykowane/kimsufi.xml

http://castpol.pl/

https://www.sprintdatacenter.pl/65/linia-eco

http://vipower.pl/

http://biznes-host.pl/

Napisz do nich prośbę o ofertę na interesujący cię hosting - bądź wypisz pod co potrzebujesz. Na pewno otrzymasz profesjonalną odpowiedź ludzi którzy się na tym znają... Z wymienionych wszystkich powyżej firm korzystałem tylko z OVH/vipower i Biznes-Host... Wszystkie 3 mogę polecić...

[Pan Kot 1535]

W takim wypadku są dwie opcje - Dedyk lub ew. VPS. Pełnej autonomii nie dostaniesz nigdzie, z bardzo prostych przyczyn - takich, że serwery tylko dzierżawisz i są własnością DC.

 

Polecam ogarnąć jakiegokolwiek doświadczonego administratora, który zerknie okiem na obciążenie wszystkich tych stron i coś doradzi. Wróżenie w ciemno nie jest dobre, no chyba że sam możesz określić na bazie tego co tam hostujesz i ruchu co dokładnie potrzebujesz.

 

Generalnie zacząłbym na Twoim miejscu od serwera dedykowanego z przynajmniej dwoma dyskami, co by zrobić RAID1. RAID1 jest bezwzględnie wymagany w takich sytuacjach i albo kupujesz dedyka, który ma przynajmniej dwa dyski i takiego połączenie robi, albo kupujesz VPS'a w zaufanej firmie, która takie coś oferuje.

 

Z VPS'em jest ten problem (tak samo jak z hostingiem zresztą), że żadne parametry nie są "gwarantowane". Jeśli zależy Ci na jak to mówisz "największej autonomii" to w grę wchodzi wyłącznie dedyk i absolutnie NIC innego.

 

http://www.ovh.pl/serwery_dedykowane/kimsufi.xml

 

Serwery nie są najwyższych lotów, ale są do przetrawienia cenowo i pod kwestią podzespołów. Oczywiście interesuje Cię oferta za 79,99 lub 119,99 z powodu dysków w raidzie. Po tym jak już się ogarniesz, a liczba stron (i obciążenie) wzrośnie to przeniesiesz się na coś wyższego - następny pakiet kimsufi albo od razu serwer SP.

 

Nie ma sensu pakować zbyt dużo kasy w taki serwer, dlatego też trzeba określić czy potrzebujesz i3 (w ofercie za 119,99) czy wystarczy stary poczciwy atomik, który jest prawie, że 2x tańszy.

 

Jeśli natomiast nie interesuje Cię taka oferta "budżetowa" to musisz się indywidualnie dogadywać z polskimi DC. Weź pod uwagę, że ceny będą przynajmniej kilkukrotnie większe niż w w/w rozwiązaniu, a zatem zastanów się czy na pewno chcesz dzierżawić serwer w Polsce .

 

Dobrym pomysłem jest też kolokacja, ceny są o wiele niższe, ale za serwer ponosisz pełną odpowiedzialność (podzespoły), więc jak się coś popsuje to oczywiście telefonik będzie do Ciebie, a nie do DC .

 

Generalnie rzuciłem Ci trochę światła na to. Na pewno interesuje Cię dedyk, pytanie czy dzierżawiony czy kolokowany. Ja bym brał "na start" jednego z tych dwóch kimsufi, a później w miarę postępu dopiero myślał co dalej - nie ma sensu, żeby dobry serwer stał i się nudził, a kasa leciała w błoto.

[T 6]

Ja tego w ogóle nie widzę. Nie napisałeś, jakie to dokładnie strony, ale z Twojej wypowiedzi wnoszę, że dość istotne, ale zarazem nie są to jakieś gigantyczne witryny. O ile nie ma problemów natury wydajnościowej, to zostawiłbym to wszystko w hostingu współdzielonym -- najlepiej w dwóch różnych firmach.

 

Rozwiązania w rodzaju VPS-a czy serwera dedykowanego, którymi zajmuje się jedna osoba są z góry skazane na porażkę. Po prostu sam nie jesteś w stanie utrzymać usługi 24/7. Prędzej czy później zdarzy się sytuacja, której szybko nie ogarniesz i cała wcześniejsza oszczędność rozpłynie się w powietrzu. Pierwsze z brzegu scenariusze -- poważna awaria sprzętowa albo 0day gdy będziesz chory lub na wakacjach.

 

To samo dotyczy świadczenia hostingu niejako przy okazji Waszym klientom czy sympatykom -- zdecydowanie najlepiej wejść we współprace z normalna firmą hostingową i wynegocjować dobre ceny, niż bawić się w hosting na Kimsufi. Mamy rok 2013, a nie 1998 i pewne standardy dotyczące dostępności i bezpieczeństwa są już wymagane i dobrze, żeby zajął się tym ktoś, kto się na tym zna i ma odpowiednie zaplecze.

[Pan Kot 1535]

Awarie sprzętowe monitoruje OVH swoim systemem RTM. Znajomy wstaje rano i się dowiaduje, że jego dedyk nie działał od ok. 04:23 bo kości ram siadły i już o 04:31 miał nowe kości i stał na nogach. Fajne uczucie, nie powiem.

 

Na 0day można ogarnąć unattended-upgrades, już w ogóle nie wspominając o grsecurity, paxie i generalnie tym co można tam zdziałać.

 

Do czego zmierzam? Wszystko się da, kwestia ogarnięcia i umiejętności. Każdy kiedyś zaczynał i jeżeli autor ma zamiar dowiedzieć się nieco więcej niż to jak wrzucić strony na ftp'a swojej firmy hostingowej to nie ma żadnych przeszkód zacząć. Czym jest hosting współdzielony jak nie dedykiem, ewentualnie kilkoma?

 

Zgadzam się, że do administracji trzeba mieć pewną smykałkę i lepiej, żeby zajęła się tym osoba która się zna, ale absolutnie nie zgadzam się z tym, że dedyk jest mniej bezpieczny niż hosting współdzielony. Ja na swoim serwerze zautomatyzowałem wszystko do tego stopnia, że system sam tworzy sobie configi, rekompiluje kernela, odpala go o 5:00 w nocy, jak nie wstanie fallback do starego + do mnie mail, jak wstanie również mail + test stabilności. Kernel panic = fallback do starego.

 

Da się? Da się. I nie potrzeba dużo czasu na monitorowanie tego, kwestia odpowiedniego pomysłu i ogarnięcia. Nawet jeśli coś "nie pyknie" to i tak zawsze można zrobić fallback z backupu i wystosować maila. Ja przez (uwaga) ponad rok takiego działania miałem 2 takie maile - jeden jak system sobie nie poradził z automatyczną interpretacją configu z kernela 3.8 na 3.9 (to ostatnio), a poprzednio jak mi jakąś funkcję z nginxa wycofali i system nie mógł odczytać configów bez poprawki. Tyle. Łączny czas? 15 min, max 30, na rok.

[lugu 0]

Dziękuję serdecznie za wszystkie sugestie! Będę to sobie wszystko jeszcze dokładnie analizował.

 

Zastanawia mnie za to, dlaczego nikt nawet nie zająknął się na temat chmury Oktawave? Czy to jest aż tak złe i niepolecane rozwiązanie? Mój prywatny blog oraz jeszcze jeden projekt od pewnego czasu siedzą sobie w Zenboxie i muszę powiedzieć, że wydajność jest znakomita. A przecież - jak oczywiście doskonale wiecie - Zenbox siedzi sobie w chmurze Oktawave. Gdzie jest haczyk?

[Pan Kot 1535]

Haczyk jest w cenach. Dla niewielkich stron i blogów może to być "jeszcze do zniesienia", ale przy pewnym pułapie unikalnych wejść robi się to już mniej opłacalne niż mając dobrze skonfigurowanego dedyka, który jest w stanie przyjąć 4x więcej, za cenę 4x mniejszą. Plusem zenboxa/oktawave jest skalowalność i to, że nie musisz się martwić o aspekty sprzętowe - płacisz, wymagasz. Nie potrzebujesz żadnej wiedzy. W przypadku dedyka/VPS'a potrzebujesz albo dość wyrafinowanej wiedzy jak to postawić, żeby było dobrze albo administratora, który to zrobi za Ciebie.

 

Poza tym to zależy od endusera. Ja jestem zwolennikiem dedyków i pełnej autonomii, ale również są klienci/administratorzy którzy nie chcą się tym zajmować, a liczy się dla nich efekt końcowy.

[T 6]

Awarie sprzętowe monitoruje OVH swoim systemem RTM.

Tak, raz np. z powodu DDoS-u wymienili "electric connector". Tego typu monitoring wychwytuje tylko część awarii i generuje sporo fałszywych alarmów.

 

Na 0day można ogarnąć unattended-upgrades

Mam wrażenie, że nie do końca rozumiesz pojęcie "0day".

 

Do czego zmierzam? Wszystko się da, kwestia ogarnięcia i umiejętności.

No właśnie nie, bo jakich byś nie miał umiejętności to on-line 24/7 nie będziesz. A tego wymaga produkcja.

 

Czym jest hosting

współdzielony jak nie dedykiem, ewentualnie kilkoma?

Sprzętem (macierze dyskowe, redundancja) i personelem (administratorzy dostępni 24/7). Oczywiście mówię tu o tych droższych ofertach.

 

Ja przez (uwaga) ponad rok takiego działania miałem 2 takie maile - jeden jak system sobie nie poradził z automatyczną interpretacją configu z kernela 3.8 na 3.9 (to ostatnio), a poprzednio jak mi jakąś funkcję z nginxa wycofali i system nie mógł odczytać configów bez poprawki. Tyle. Łączny czas? 15 min, max 30, na rok.

Do czasu, do czasu...

[Pan Kot 1535]

Tak, raz np. z powodu DDoS-u wymienili "electric connector". Tego typu monitoring wychwytuje tylko część awarii i generuje sporo fałszywych alarmów.

 

Mam wrażenie, że nie do końca rozumiesz pojęcie "0day".

 

No właśnie nie, bo jakich byś nie miał umiejętności to on-line 24/7 nie będziesz. A tego wymaga produkcja.

 

Sprzętem (macierze dyskowe, redundancja) i personelem (administratorzy dostępni 24/7). Oczywiście mówię tu o tych droższych ofertach.

 

Do czasu, do czasu...

 

1. Pewnie, że nie. Ale wszystkie ważniejsze kwestie wyłapie - jeśli serwer wpadnie w downtime to od razu w rtm im się zaświeci, a to właśnie ich zadaniem jest naprawić to tak, żeby serwer działał. Oczywiście jest opcja wielu fałszywych alarmów i jak najbardziej się z tym zgadzam, ale nie powiesz mi że w przypadku awarii shareda ktoś zacznie szybciej działać niż w przypadku awarii dedyka .

 

2. Pardon, źle się wyraziłem. Chodziło mi głównie o grsecurity, paxa i unattended-upgrades. Jeśli 0day by istniał na dowolną aplikację x to mówiąc szczerze na dzień dzisiejszy jestem przekonany, że nie ma shareda który ma nowsze pakieciki i kernela od mojego dedyka oraz takiego, w którym administratorzy by to szybciej aktualizowali niż moja automatyzacja. A jeśli jest to 0day w jakimś skrypcie np. WP to również na sharedzie byłby exploitable.

 

3. Owszem produkcja tego wymaga, ale rodzaje awarii mamy w zasadzie dwa - jeden rodzaj to awaria sprzętowa, w której i tak musi zareagować firma, a drugi rodzaj to awaria software'owa, która z dnia na dzień sama się nie stwarza - od tego są odpowiednie narzędzia monitorujące, żeby nagle się nie dowiedzieć że serwer padł.

 

4. Tu się zgadzam, ale mało który shared oferuje coś więcej niż 2 dedyki (www/mysql) z macierzą raid1/5/10, a coś takiego można stworzyć we własnym zakresie.

 

5. Pewnie, że do czasu. Nic nie trwa wiecznie, ale zachowując minimum automatyzacji i czystości serwera jesteś bez problemu w stanie ogarnąć (np. w debianie) tylko security update'y wszystkich swoich krytycznych apek (nginx, apache, mysql, cokolwiek) i jesteś pewny, że się nie rozwalą z powodu błędów w konfiguracjach czy zmienionego kodu.

Edytowano Czerwiec 14, 2013 przez Archi (zobacz historię edycji)

[T 6]

1. Pewnie, że nie. Ale wszystkie ważniejsze kwestie wyłapie - jeśli serwer wpadnie w downtime to od razu w rtm im się zaświeci, a to właśnie ich zadaniem jest naprawić to tak, żeby serwer działał. Oczywiście jest opcja wielu fałszywych alarmów i jak najbardziej się z tym zgadzam, ale nie powiesz mi że w przypadku awarii shareda ktoś zacznie szybciej działać niż w przypadku awarii dedyka .

Z moich doświadczeń wynika, że w produkcji taki monitoring najlepiej wyłączyć.

 

2. Pardon, źle się wyraziłem. Chodziło mi głównie o grsecurity, paxa i unattended-upgrades. Jeśli 0day by istniał na dowolną aplikację x to mówiąc szczerze na dzień dzisiejszy jestem przekonany, że nie ma shareda który ma nowsze pakieciki i kernela od mojego dedyka oraz takiego, w którym administratorzy by to szybciej aktualizowali niż moja automatyzacja.

Zapewniam, że jest wiele sharedów, gdzie administrator nałoży patcha zanim pojawi się on w security updates danej dystrybucji.

 

4. Tu się zgadzam, ale mało który shared oferuje coś więcej niż 2 dedyki (www/mysql) z macierzą raid1/5/10, a coś takiego można stworzyć we własnym zakresie.

Mówimy o budżecie rzędu kilkuset złotych miesięcznie -- to wystarczy na kilka kont "premium". Chyba nie próbujesz porównywać serwera dedykowanego z kontem za 50 zł rocznie.

 

No i przede wszystkim -- może odniósłbyś się konkretnie do faktu, że jedna osoba nie jest w stanie obsługiwać serwera 24/7, a produkcja tego wymaga. Co zrobisz w sytuacji awarii wymagającej ludzkiej interwencji, której nie będziesz w stanie wykonać, bo będziesz off-line przed dłuższy czas?

[Pan Kot 1535]

No i przede wszystkim -- może odniósłbyś się konkretnie do faktu, że jedna osoba nie jest w stanie obsługiwać serwera 24/7, a produkcja tego wymaga. Co zrobisz w sytuacji awarii wymagającej ludzkiej interwencji, której nie będziesz w stanie wykonać, bo będziesz off-line przed dłuższy czas?

 

Wiesz... "Fizyczna" interwencja w tym momencie należy do administratorów firmy, u której dzierżawimy serwer. Z kolei jeśli chodzi o samego działającego dedyka to owszem jak najbardziej masz tutaj całkowitą rację, ale wciąż uważam że dobry admin jest w stanie zautomatyzować przynajmniej 50-70% zadań, przykładowo - jeśli serwer http nie odpowie (poprawnie) na 3 requesty z rzędu (zakładamy 1 request / minute monitoring) to wykonuje jakieś service nginx+php5-fpm+varnish+xxx restart, potem sprawdza czy wstało, jak nie wstało e-mail/sms do admina.

 

Produkcja z dnia na dzień się nie psuje - dyski można monitorować smartem (a do tego mamy macierz raid1), w przypadku innych podzespołów firma je wymienia, a z kolei software'owo dobrze ogarnięty dedyk nie powinien również sprawiać problemów - serwery same się nie psują .

[kafi 2425]

 

 

jeśli serwer http nie odpowie (poprawnie) na 3 requesty z rzędu (zakładamy 1 request / minute monitoring) to wykonuje jakieś service nginx+php5-fpm+varnish+xxx restart, potem sprawdza czy wstało, jak nie wstało e-mail/sms do admina.

IMO bardziej wartościowe jest sprawdzenie przez dyżurnego przyczyny anomalii i podjęcie selektywnych działań, niż restartowanie na pałę wszystkiego, co się da. Potem może być za późno na jakąś diagnostykę...

 

 

 

"Fizyczna" interwencja w tym momencie należy do administratorów firmy, u której dzierżawimy serwer.

No ale musisz powiadomić ową firmę o tym. Ustalić termin wymiany. Zatrzymać usługi. Potem zweryfikować, czy wszystko wstało...

Z automatu się tego nie zrobi (a ja osobiście nie chciał bym, aby owa firma wyłączyła mi serwer pstryczkiem kiedy jej pasuje - czyli w godzinach, w których z usług na tym serwerze korzysta najwięcej osób

 

 

 

na dzień dzisiejszy jestem przekonany, że nie ma shareda który ma nowsze pakieciki i kernela od mojego dedyka oraz takiego, w którym administratorzy by to szybciej aktualizowali niż moja automatyzacja

Jak trzymasz tam tylko swoje zabawki, to możesz sobie aktualizować do woli. Najwyżej jak coś zepsujesz nowymi wersjami, to swoje aplikacyjki webowe poprawisz. Ale w środowisku współdzielonym (i to jeszcze jakimś chociażby kilkunastoserwerowym) musisz liczyć się z tym, że każdy update może spowodować, że jakiś badziewnie napisany skrypt przestanie działać. A to rodzi telefony/zgłoszenia/etc. których obsługa zabieraja czas Jak dołożysz podejście roszczeniowe klientów (skoro działało, to dalej ma działać i klient ma to w dupie) to szybko wyleczysz się z unattended uprades na takich środowiskach

[T 6]

Wiesz... "Fizyczna" interwencja w tym momencie należy do administratorów firmy

Jasne, jak sam nie sprawdzisz co jest nie tak i nie pokażesz palcem to masz dużą szanse, że wymienią Ci nie to co trzeba albo zajmie im to trzy razy więcej czasu. Informacje zazwyczaj są w logach, do których technicy nie mają dostępu.

 

dobry admin jest w stanie zautomatyzować przynajmniej 50-70% zadań

Może nawet i 95%, ale problemem jest właśnie to co zostaje. Trzech dobrych adminów może spokojnie ogarnąć 30-60 maszyn, ale jeden nie ogarnie (bez ryzyka długiego przestoju) nawet jednej.

 

Produkcja z dnia na dzień się nie psuje - dyski można monitorować smartem (a do tego mamy macierz raid1), w przypadku innych podzespołów firma je wymienia, a z kolei software'owo dobrze ogarnięty dedyk nie powinien również sprawiać problemów - serwery same się nie psują .

Było tu już wielu takich, którzy tak uważali. Kończyło się zwykle podobnie.