3 serwery na start duzego portalu

[Pawel I 0]

Mój klient zaczyna poważnie myslec o porzadnej platformie pod 2 swoje spore portale.

Wyczytalem tutaj na forum ze dobrym rozwiazaniem jest nast. rozdzielenie serwerow:

Na poczatek 3 serwery:

1. serwer mysql

2. serwer aplikacyjny (PHP)

3. serwer tresci statycznej (obrazki, css, js, strony statyczne wygenerowane przez serwer aplikacyjny).

 

Kazdy z tych serwerow mialby stac na najwydajniejszym serwerze do danego typu zadan czyli np. apache, ngix, litespeed itp. - jakie serwery polecacie do tych 3 konkretnych zadan.

 

Jak pozniej rozbudowywac te infastrukture gdy braknie mocy bez wiekszego przebudowywania aplikacji.

W przypadku serwer mysql z tego co sie orientuje jest to najproszta sprawa.

A w przypadku reszty ?

 

Jednak mam pytania natury programistycznje (oskryptowanie php strony).

Czy da sie tak zrobic aby jakos "zlinkowac" serwer 1 i 2 - chodzi mi dokladnie o to zeby serwer aplikacyjny PHP mogl korzystac z miejsca na serwerze 3 (tresci statycznej) tak jakby to byl tylko 1 serwer.

Dokladniej chodzi mi o to zeby latwo rozwiazac sprawe wgrywanych na serwer za pomoca php obrazkow i ich resize itp - korzystajac z 1 serwera sprawa jest prosta - bo obrazki wgrywany do odpowiedniego folderu - robimy resize itp.

W przypadku 2 serwerow nie mam pojecia jak rozwiazc te sprawe bez "zlinkowania" serwerow.

 

Jako "linkowanie" mam na mysli m.in takie rozwiazanie ze logujac sie na serwer ftp serwera aplikacyjnego PHP mam dodatkowo wyswietlone foldery z serwera tresci statycznej i dzieki temu w prosty sposob za pomoca php molgbym robic operacje na wgrywanych obrazkach oraz w latwy sposob bym generowal i kasowal strony statyczne za pomoca PHP.

 

Jesli chodzi o serwer tresci statycznje to kolejne foldery dla danej domeny beda stac na osobnych subdomenach np. js.domena1.pl, user_img.domena.pl, gfx.domena.pl itp.

 

Bardzo prosze o sugestie jak to rozwiazac najsensowniej aby przy braku mocy latwo to wszystko rozbudowac oraz czy da sie "zlinkowac" te serwery php i statyczne ?

 

Pozdrawiam

[Pienio69 4]

LoadBalancery

[Gość Kamikadze]

Możesz rozłożyć ruch na kilka serwerów

 

Rozdzielanie stron (w sensie wszystko oddzielnie) na 3 serwery MOIM zdaniem nie jest dobrym rozwiązaniem gdyż jak padnie ci jeden to albo nic nie działa albo masz sieczke na stronce. Ogólny efekt także może nie być zadowalający ze względu na takie samo obciążanie wszystkich serwerów na raz niż kilku po trochu (w przypadku loadbalancera)

 

 

Jeżeli zaczyna dopiero to może skorzystać z jednego serwera później dokupić drugi itd.

 

 

Co do serwerów WWW to apache chyba będzie najgorszym wyjściem (nie wiem jak ten nowy)

[elcct 159]

To wszystko zależy od aplikacji architektury itd. czasami dobrze jest sobie tak rozdzielić, a czasami użyć zupełnie innych rozwiązań.

W tym co proponujesz, ważne by serwery były w tym samym dc i miały ze sobą bezpośrednie spięcie najlepiej 1gbit, a idealnie 10gbit.

Nie da się określić w jaki sposób można aplikacje skalować bez wglądu do kodu, a rozbudowa serwera bazy nie jest wcale łatwa.

Polecam poczytać sobie bloga High Scalability http://highscalability.com/ są czasem opisywane konkretne przypadki skalowania itd.

 

Co do "łączenia" serwerów są różne metody. Możesz użyć NFS - sieciowego systemu plików i sobie podmontować katalog z innego serwera,

możesz obrazki po obróbce przesłać za pomocą rsync albo jak sobie zrobisz storage kompatybilny z s3 jakąś libką od amazona,

możesz też sobie zrobić cdn, że w przypadku pierwszego zapytania serwer sam sobie pobierze od serwera aplikacji obrazek...

wszystko zależy od aplikacji, jak w przyszłości chcesz skalować.

 

Nie ma złotego środka...

[Gość Bartosz Gadzimski]

Czym więcej informacji napiszesz tym łatwiej będzie coś doradzić.

 

Najlepiej znaleźć kogoś kto ma doświadczenie i niestety mu zapłacić (administratorowi/firmie).

 

To serio jest bardzo zależne od danego przypadku.

 

Czasami warto kombinować, a czasami lepiej kupić jeden bardzo mocny serwer i już.

 

Jak kombinujesz to powtórzę, znajdź kogoś kto to ogarnie i będzie się tym zajmował.

 

Przedstawiona konfiguracje to stosunkowo mało problemów i dobry punkt wyjścia natomiast to już 3 maszyny do opieki.

[elcct 159]

Projekt w pełni profesjonalny?

Pliki statyczne amazon s3, a pozostałe maszynki to jakaś przyzwoita kolokacja (beyond, thinx)

 

Dlaczego amazon ? Jesli ruch na Polskę, to szybszy i tańszy jest dedyk w OVH, co do serwerów aplikacyjnych się zgadzam im bliżej klienta tym lepiej, tylko nie wiem czy nie zbankrutujesz kupując w Polsce. Trafik jest zbyt drogi.

[Pawel I 0]

Witam.

Poprzegladalem troche konfiguracji tych baardzo duzych serwisow na http://highscalability.com/

 

Jesli klient sie juz zdecyduje na 100% to na pewno komuś to zlece bo akurat na stawianiu i administrowaniu serwerow nic sie nie znam.

A w tym temacie nie tylko szukam oferty ale takze chce sie dowiedziec o roznych rozwiazaniach tak dla siebie zeby piszac aplikacje od poczatku wprowadzac rozwiazania dobrze skalowalne.

 

Widze ze tam baardzo wiele serwisow korzysta z memcached i do tego celu stosuje bardzo wiele dodatkowych serwerow - widze w ogóle ze stosujac memcached latwo pisze sie aplikacje ktora bedzie wykorzystywac czy to 1 serwer czy N serwerow.

Z tego co widze tak samo memcached jest chyba najlepszym sposobem do przechowywanie sesji z wielu serwerow (widzialem ze kilka linijeczek kodu przy konfiguracji serwera memcached zalatwia te sprawe).

 

Tylko ze tutaj najpierw trzeba pomyslec jak rozwiazac sprawe jak 1 serwer mysql przestanie wyrabiac mimo zastosowania memcached oraz kwestia rozbudowy serwerow aplikacji - tutaj akurat chyba najbardziej rozsadny jest load balancer i kilka serwerow aplikacji.

Tylko prosze mi napisac jak wyglada sprawa przechowywania tych samych plikow uzytkownikow na kazdym z serwerow jak nie stosujemy osobnego serwera CDN to przechowywania np. obrazkow itp. - czy stosujac loadbalancer od razu jestesmy zmuszeni do osobnego serwera plikow statycznych ?

Jak w przypadku stosowania loadbalancera i wielu serwerow aplikacji wyglada sprawa np. modyfikacji oprogramowania php ? Jak cos zmodyfikujemy na jednym serwerze to jak z automatu modyfikowac zawartosc na wszystkich serwerach ?

 

Z gory dzieki za rzeczową dyskusję

Edytowano Marzec 8, 2012 przez Pawel I (zobacz historię edycji)

[Gość Kamikadze]

Możesz sobie ustawić synchronizację wszystkiego w przypadku LB

 

 

Poczytaj również o chmurce bo może Twojemu klientowi się spodoba (i dopasuje pod swoje wymagania):

 

http://pl.wikipedia.org/wiki/Chmura_obliczeniowa

 

A reszte artykułów sobie wygoglujesz

[alien 345]

Z tymi chmurami to ja bym zalecał ostrożność. To się fajnie czyta o skalowalności, ale można się zdziwić, gdy się wyskaluje taką wirtualkę w chmurze do rozmiaru jednego mocnego serwera i... dalej się już nie da :-). Albowiem chmury w kontekście e24cloud czy Amazona to nic innego jak VPS zapakowany w trochę elastyczniejszy model rozliczeniowy oraz z większą dostępnością (*). Poza jedną fizyczną maszynę nie wyjdzie.

 

(*) Przy klastrze HA takiego VM Ware czy Hyper-V zachowana zostaje odporność na wypadek awarii serwera, drugi serwer w klastrze powinien przejąć maszynę wirtualną. Wymagane jest natomiast podmontowanie systemu plików z zewnętrznego źródła (macierzy) - kolejny punkt potencjalnej awarii do rozwiązania, choć można zapewnić redundancję elementów macierzy na poziomie kontrolera, dysków.

Edytowano Marzec 8, 2012 przez alien (zobacz historię edycji)

[Gość Kamikadze]

Miałem na myśli coś takiego: http://www.ovh.pl/private_cloud/

[alien 345]

Miałem na myśli coś takiego: http://www.ovh.pl/private_cloud/

 

Problemy pozostają te same. Nadal skalujemy VM do rozmiaru jednego serwera, jeśli braknie - dostawiamy kolejny serwer i na nim odrębną VM. To jest kluczowa sprawa na etapie projektowania systemu przede wszystkim w warstwie aplikacji - trzeba założyć, że system będzie musiał obsłużyć wiele serwerów rozumianych jako niezależne systemy. I żaden cloud made by VM Ware, Citrix czy Microsoft przed tym nie uratuje.

 

To są detale, o których się nie myśli gdy projekt jest mały, ale które są problemem przy skalowaniu gdy projekt rośnie ("efekt naszej klasy"). Jeśli aplikacja nie była dostosowana do load balancingu to się może okazać, że po odpaleniu takich skryptów PHP na dodatkowym serwerze coś nie zadziała. Jeśli aplikacja nie wspiera replikacji SQL to znów jest problem. Dlatego load balancing warto przewidywać już na etapie projektowania aplikacji (jeśli oczywiście założenie obejmuje znaczący rozrost serwisu; przy mniejszym rozroście podział funkcjonalny serwerów na np. serwer aplikacji, serwer baz danych, serwer poczty/static powinien być zupełnie wystarczający, a mniej problematyczny).

 

No i dochodzimy do wniosku, że taki Private Cloud OVH nie różni się wiele od zakupu odrębnych serwerów, macierzy i zastosowania wirtualizacji we własnym zakresie, poza tym, że fakturę płacimy w jednym miejscu. No i są też alternatywne sposoby realizacji HA (np. bazujące na drbd). Lepszy? Gorszy? Kwestia rozwiązania.

Edytowano Marzec 8, 2012 przez alien (zobacz historię edycji)

[Gość Kamikadze]

No i dochodzimy do wniosku, że taki Private Cloud OVH nie różni się wiele od zakupu odrębnych serwerów, macierzy i zastosowania wirtualizacji we własnym zakresie, poza tym, że fakturę płacimy w jednym miejscu. No i są też alternatywne sposoby realizacji HA (np. bazujące na drbd). Lepszy? Gorszy? Kwestia rozwiązania.

 

Nie testowałem a tylko dałem informacje aby się zapoznał z tym W końcu klient zdecyduje

 

 

Ogólnie nie ma idealnego rozwiązania. Trzeba aplikację odpowiednio przystosować do odpowiedniej infrastruktury tak jak to napisałeś.

 

 

Rzucam tylko pomysły Warto żebyś także coś powiedział na ten temat bo widzę że masz dużą wiedzę.

[kaszub1136 109]

jeżeli to duży projekt to też jest duży budżet. Jak potrzebujesz elastycznej oferty to zerknij na https://www.e24cloud.com/

[alien 345]

Warto żebyś także coś powiedział na ten temat bo widzę że masz dużą wiedzę.

 

Trudno się tu odnieść do tematu bez dokładnego zgłębienia specyfiki tworzonego systemu. Tworzenie rozwiązań HA i Load Balancing to jest zawsze szukanie indywidualnych kompromisów.

 

Podam przykład - Pawel I chce osiągnąć efekt widoczności tych samych danych na dwóch serwerach aplikacji. Najprostszym rozwiązaniem jest podmontowanie systemu po NFS z jednego serwera aplikacji (A) na drugi serwer aplikacji (B ). Jest to rozwiązanie najprostsze, ale niosące ze sobą stratę wydajności (zależność wydajności na serwerze B od systemu serwera A). Jest też problem niezawodności, ponieważ w razie awarii serwera A, serwer B nie będzie miał dostępu do danych.

 

Chcąc rozwiązać te problemy należałoby sięgnąć po inne rozwiązanie, np. zewnętrzny NAS dostarczający dane na serwer A i B. Rozwiązanie droższe, a do tego podatne na awarię serwera NAS (one point of failure), dlatego chcąc się przed tym zabezpieczyć należałoby sięgnąć po dodatkową redundancję po stronie NAS lub macierz z redundantnymi kontrolerami (ale tylko z systemem plików pozwalającym na jednoczesny dostęp zdalny z dwóch maszyn). To znów podnosi koszty. No i obniża (nieznacznie lub znacznie - zależnie od różnych czynników) wydajność dostępu do danych w porównaniu do systemu dyskowego bezpośrednio na serwerze, więc niekiedy nie warto iść w tę stronę jeśli system jeszcze nie wymaga rozwiązań HA czy load balancingu.

 

Sprawa się jeszcze skomplikuje, jeśli zauważymy, że zwykle rozwiązania w kierunku zapewnienia High Availability niekoniecznie idą w parze z rozwiązaniami w kierunku Load Balancingu (wyjątek: drbd, ale nie bez dodatkowych zastrzeżeń) i wymagają odrębnych nakładów sił i środków w jednym i drugim przypadku.

 

Także w takich tematach nie ma złotego środka. Jedno rozwiązanie będzie dobrym kompromisem dla jednego projektu systemu, ale nie sprawdzi się przy innym systemie. Takie rzeczy trzeba konsultować indywidualnie.

Edytowano Marzec 8, 2012 przez alien (zobacz historię edycji)

[Gość Kamikadze]

Tutaj im więcej pomysłów i im więcej rozwiązań tym lepiej - klientowi przedstawi plusy i minusy każdej z nich i klient wybierze

[alien 345]

Tutaj im więcej pomysłów i im więcej rozwiązań tym lepiej - klientowi przedstawi plusy i minusy każdej z nich i klient wybierze

 

Z doświadczenia - warto zacząć od określenia budżetu :-). Wodze fantazji administratora systemów mogą być praktycznie nieograniczone, niestety warto je już na początku skonfrontować z rzeczywistością.

[huan 18]

Jak już zostało napisane: wszystko zależy od samej aplikacji.

 

Ja bym proponował coś takiego:

 

Na frontendzie nginx i w nim ustawić load balancing na serwery z PHP-FPM (nginx ma wbudowany dość prosty mechanizm load balancingu). Ten sam nginx mógłby jednocześnie serwować pliki statyczne. Jeśli naprawdę ruch jest liczony w milionach dziennie, to ewentualnie load balancing na bazie DNSów do różnych instancji nginxa na kilku serwerach.

 

Na serwerach gdzie działa PHP zainstalować php cache np. Xcache + przerobić oprogramowanie portalu, aby wykorzystywało memcache.

 

Jeśli aplikacja wykonuje wiele operacji na bazach, to dedykowana maszyna tylko do MySQLa. Najlepiej Percona MySQL5.5 - bardzo dobrze radzi sobie przy dużym obciążeniu.

 

Jeśli chodzi o współdzielenie plików między serwerami, to NFS nie jest zbyt wydajne i jeśli synchronizacja może odbywać się np. co kilka minut, a nie w czasie rzeczywistym, to wystarczy prosty rsync w crontabie.

Edytowano Marzec 10, 2012 przez huan (zobacz historię edycji)

[trustnet 38]

Z mojego doświadczenia działa to tak:

 

Jak nie budujesz drugiego onetu, to często nie będzie potrzeby stawiania kilku serwerów: mam doświadczenie z kilkoma dużymi portalami w skali Polski i mogę zaryzykować stwierdzenie, że w większość przypadków wystarczy jeden serwer. Ten serwer nie powinien to być jednak wrak i zabytek, ale coś nowoczesnego (tutaj znaczenie będą miały takie parametry jak raid sprzętowy, wydajne dyski np. SAS, szybki RAM - rzeczy banalne, ale często niedoceniane pod względem wydajności). Większość problemów z dużymi portalami to problemy, powiedzmy ogólnie, "programistyczne" a nie sprzętowe.

 

Spotkałem się już z bazą gdzie tabele miały po 400milionów rekordów i podejście było, że tylko Oracle to łyknie na klastrze serwerów (przy dużym obciążeniu), a potem okazało się, że postgres z poprawną optymalizacją zapytań, indeksów, klastrowaniem itd i śmiga aż miło na pojedynczej maszynie. Niemniej to wymagało dużo pracy.

 

Zatem bardziej bym się skupił na budowie tego portalu a nie na sprzęcie. Bo programiści to czynią cuda czasem (szczególnie tacy od php+mysql ;-) ). Trzeba zwrócić uwagę na cachowanie na wszelkie możliwe sposoby, optymalizację zapytań.

 

Najlepiej wybrać agencję, która będzie to stale obsługiwała i np. zaproponuje też rozwiązania serwerowe - skoro Ty - jak piszesz się na tym nie znasz. Bo inaczej możesz kupić coś, za co zapłacisz "jak za zboże" a i tak może być niewydajne, bo aplikacja to wykończy.

 

Tym powinien zająć się ktoś (w sensie firmy), kto to będzie tez obsługiwał i za działanie odpowiadał :-)

[Misiek08 285]

Tak jak @trustnet napisał. Niewiele projektów potrzebuję w początkowym stadium więcej niż 1 serwera, a większa część na 1 serwerze też kończy. Nie pakuj pieniędzy w błoto, tylko daj to komuś kto oceni ile rzeczywiście potrzebna. Dodatkowo warto gdybyś miał pewność jakości kodu takiego portalu, bo znowu @trustnet napisał, że postgre też uciągnie dużo, jeśli tylko i baza i front-end będą do tego stworzone.

[trustnet 38]

To jeszcze dorzucę jeden przykład: jak będzie dużo fotek, to zwróć uwagę na taki "detal" jak ich umieszczenie. Miałem już serwer z portalem, gdzie nikt nie wiedział, czemu "wolno działa". Próba wydania komendy "ls" w katalogu z fotografiami powodowała zwis konsoli na 3-4 minut. plików było prawie pół miliona w jednym katalogu ....

[alien 345]

Większość problemów z dużymi portalami to problemy, powiedzmy ogólnie, "programistyczne" a nie sprzętowe.

 

Zadam przewrotne pytanie - łatwiej o drugi serwer czy o dobry zespół programistów? ;-).

[theONE 526]

Do tego serwery mozna amortyzowac albo dofinansowac

[trustnet 38]

taaa, a od programistów najczęściej nie można odliczyć VAT-u

 

zatem wszystko jasne, gdzie jest wąskie gardło i co jest kosztowne

[theONE 526]

Nie no jeszcze leasing i przewidywalność kosztów po zakupieniu

 

Przy niektórych projektach lepiej wydać więcej na sprzęt niż na programistów ale trzeba wiedzieć co się robi

[trustnet 38]

no właśnie chodzi jednak nie o serwery, a o programistów .... brutalna prawda, ale programista programista może wykończyć każdą maszynę ...