struktura serwerów

[wkurzony]

Poszukałem w necie trochę, znalazłem prezentację serwerów GG i mam komentarze do niej. Z góry przepraszam, jeżeli powstanie bałagan w wypowiedzi.

1. Slajd numer 2 pozycja 1. Powinno być CPU zamiast PCU. Swoją drogą 2,5 mln procków.... ile pomieszczeń zajmuje szafa z tyloma układami?
2. Slajd numer 5 pozycja 1. NDB - specjalna baza MySQL (MySQL cluster). Słowo 'cluster' po polsku znaczy po prostu klaster (czyli węzeł połączeniowy. Baza MySQL nie może być węzłem połączeniowym - może nim być serwer, switch bądź hub.
3. Slajd numer 5 pozycja 3. Spread. Nie musieliście tworzyć żadnej aplikacji w tym celu. Ten sam poziom kontroli (monitorowanie pakietów) daje CSM Cisco.
4. Slajd 6 pozycja 1. Baza trzymająca dane w pamięci. Chodzi o MySQL tak?
5. Slajd 6 pozycja 2. Wyrabiałoby się gdybyście dostawili więcej racków.
6. Slajd 6 pozycja 3. Każda infrastruktura jest wrażliwa na problemy sieciowe - jest to całkiem normalne. Po to właśnie są firewall'e, wielokrotne obwody AC itd.
7. Slajd 8 pozycja 2. Każdy serwer trzyma swoją mapę w pamięci. Po pierwsze nie w pamięci tylko na dysku głównym (MHDD), a po drugie - jest to chyba całkiem normalne, że każdy serwer przechowuje mapę swojego 'otoczenia sieciowego' - inaczej każda zmiana topologii byłaby związana ze zmianą mapy (wg nazewnictwa prezentacji) co z kolei wydłużałoby czas offline serwera, czyli generowałoby straty. To co Wy nazywacie mapą, nazywa się indeksem topologicznym sieci. Mapa sieciowa jest to graficzne podsumowanie lokacji poszczególnych IP naniesione na rzut budynku (skrzydła), bądź konkretnych pomieszczeń. Informacje o logowaniach i wylogowaniu trafiają do logów danego serwera.
8. Slajd 8 pozycja 3. Nie musieliście. Wystarczyło ponownie wpisać do CLI polecenie ustawiające timeout.
9. Slajd 9 pozycja 1. patrz punkt 6.
10. Slajd 9 pozycja 2. Nie musielibyście. A nawet jeżeli dostalibyście takowe zadanie, to skoro jednego Spreada już napisaliście, napisanie drugiego nie stanowiłoby problemu?
11. Slajd 9 pozycja 3. Wystarczyłoby utworzyć kilka baz danych, powiązać je odpowiednimi relacjami i dałoby radę. Bazy danych takich firm jak Google przetwarzają kilkaset tysięcy operacji odczytu na sekundę i jakoś dają sobie radę. I nie ma problemów z przeplotami.

[Qrix]

To fajnie, że odnosisz się do jakiejś prezentacji, do której namiaru nawet nie raczysz podać. Może jakiś link podaj, wtedy można się odnieść do tego materiału

[wkurzony]

prezentacja => http://crazy4ever.wrzuta.pl/sr/f/3JUrWlR6ZaR/gg-barcamp

[Tomaszek]

Nikt nie miał na myśli procesorów (CPU), tym bardziej nie ma ich 2,5 mln - chodzi o ilość zalogowanych użytkowników w tym samym momencie w szczycie. Nie rozumiesz poprawnie przyjętego znaczenia słowa cluster. Jeśli o wybór sprzętu i oprogramowania chodzi wszystko rozbija się o problem skali i odpowiednich wymagań - inaczej projektuje się architekturę dla aplikacji o małym ruchu, inaczej dla tej o większym. Należy również wziąć pod uwagę elastyczność rozwiązań, dotychczasową infrastrukturę, koszty, itp. Jest ogrom wymagań, które na pewno nie załatwisz jednym stwierdzeniem - Cisco! Slajd 6. mówi o NDB (masz w nagłówku). I tutaj znów nie wszystko załatwisz dostawieniem rzeczy X (gdzie X to aplikacja, rack, maszyna, cokolwiek innego) - działa dobrze dla 100 żądań na sekundę? Będzie działać równie dobrze dla 500? Niekoniecznie. Problem skali ponownie wchodzi w grę. Jeśli o wrażliwość na problemu sieciowe chodzi - systemy projektuje się tak, by minimalizować ryzyko niestabilności systemu przy problemach sieciowych - jeśli system jest niestabilny przy najmniejszych problemach sieciowych, to znaczy, że jest wrażliwy na problemy sieciowe. Co do reszty "uwag" - bez komentarza - albo w zasadzie z poniższym komentarzem.

Kolego, wszelkie rozwiązania wydają się idealne, stabilne, najlepsze, oczywiste do momentu zderzenia się z rzeczywistym ruchem, wysokim obciążeniem, awarią, itp. Można nabrać sporo pokory przy zderzeniu z takimi problemami. Radzenie sobie z tym wymaga sporego bagażu doświadczeń, dużej wiedzy, inteligencji i abstrakcyjnego myślenia. Zapewniam Cię, że osoby zajmujące się architekturą aplikacji serwerowych posiadają te cechy i potrafią zaprojektować architekturę pod zebrane wymagania. Uwagi w rodzaju: wiem, że rozwiązanie X jest lepsze od rozwiązania Y oderwane od otaczających projekt wymagań ciężko traktować poważnie. Jaki był w ogóle cel tego postu? Dodam, że taka prezentacja była materiałem pomocniczym do wygłaszanej prezentacji - nie jest opracowaniem mówiącym same za siebie.

Jeśli chcesz poznać ciekawostki dotyczące naszych systemów serwerowych - jesteśmy otwarci na merytoryczną dyskusję czy pytania. Jeśli natomiast chcesz w podobnie niepoważny sposób narzucać jedynie słuszną wiedzę przy zagadnieniach architektury systemów - proszę o zastanowienie się przed publikacją odpowiedzi.

[wkurzony]

dziękuję za odpowiedź. Masz sporo racji w swojej wypowiedzi.

Jesteś pierwszą osobą z GG Teamu, która na mój post napisała w pełni sensowną i prawdziwą wypowiedź bez złośliwości, dogryzań (jak to niektórzy (np botmonster) mają w zwyczaju) itp.

Dzięki wielkie Tomaszek

PS. Dłuższą wypowiedź napiszę jak tylko znajdę trochę czasu, aby wyrazić swoje myśli w tym temacie