Re: Cluster
Mam niestety tylko pomysly, brak wiedzy praktycznej, choc temat jest ciekawy. Moja propozycja: 1 host rozsylacz - portafi wykryc awarie serwera i kierowac za,dania do innego - rozdziela obciazenie n serwerow [ ] / | \ \ [ ]<->[ ]<->[ ] ... [ ] pozostaje tylko i az problem synchronizacji dancyh pomiedzy n serwerami. Czyli Linux Virtual Server. W tym miejscu przydaloby sie zewnetrzne zrodlo danych. Mozna postawic serwer z macierza dyskowa (ew. zdublowany), ktory udostepnia zasoby serwera "roboczym". Taka konfiguracja pokazana jest na stronie http://www.linuxvirtualserver.org/HighAvailability.html drbd - RAID 1 over tcp/ip for Linux utilities Jest to sposob, jednak jego podstawowa wada jest jednostronne dzialanie. Musi istniec master i slave. W normalniej konfiguracji dziala tylko jeden, drugi wlacza sie w przypadku padu mastera. Rozwiazanie sprawdzi sie np. przy dublowaniu serwera z zasobami lub routera rodzielajacego ruch. Jak natomiast zrobic cos takiego, zeby kilka maszyn korzystalo z tego samego zrodla danych, moglo czytac/zapisywac i pozostale maszyny by to "widzialy". Ciekawym projektem jest CODA, ale z tego co czytalem zastosowanie go w obciazonych serwerach raczej nie jest dobrym pomyslem (przynajmniej autorzy projektu nie znaja takiego wdrozenia). Ostatecznie mozna dane udostepniac po NFS, ale nie wiem jak z wydajnoscia takiego rozwiazania. Jezeli wydajnosc nie jest problemem, to moze lepiej zainwestowac w dobry serwer ktorego awaryjnosc jest akceptowalna, anizeli konstruowac klastry, ktorymi chyba trudniej zarzadzac? ( pozostaja jeszcze wzledy ekonomiczne) A co w momencie, gdy mamy bardzo wymagajaca wirtualke ? Taka ktora zabije nawet lepsze serwery ? W moim przypadku bardziej obciazenie bedzie dokuczliwe niz awarie serwerow. Chcialbym wiec zaprojektowac rozwiazanie maloawaryjne, ale wydajne. Co do wzgledow ekonomicznych to masz racje. To sa na razie plany :(. Moze jest ktos na liscie moglby sie podzielic swoim doswiadczeniem w budowie takich maszyn. -- Maciej Gasiorowski
Re: Cluster
On Mon, 26 Apr 2004 18:55:19 +0200 Gasior <[EMAIL PROTECTED]> wrote: > Idealne byloby dla mnie takie rozwiazanie, zeby serwery na ktorych > dzialaja uslugi dzielily w jakis sposob dyski. Zapis moglby nastepowac > na obojetnie ktorym z nich i widoczny bylby na pozostalych. > > Z tego co znalazlem na sieci to istnieja jedynie rozwiazania, gdzie > jeden z serwerow jest masterem, drugi synchronizuje sie z niego. W > przypadku padu mastera, zamieniaja sie miejscami. Tak konfiguracja nie > balansuje jednak ruchu, poniewaz zazwyczaj pracuje sam master, a drugi > serwer "czeka" na jego pad. > > Synchronizacja przez rsync i pochodne raczej odpada, zakladam bowiem ze > w ciagu dnia moze byc sporo zmian na dysku (mail, ftp itp.). Mam niestety tylko pomysly, brak wiedzy praktycznej, choc temat jest ciekawy. Moja propozycja: 1 host rozsylacz - portafi wykryc awarie serwera i kierowac za,dania do innego - rozdziela obciazenie n serwerow [ ] / | \ \ [ ]<->[ ]<->[ ] ... [ ] pozostaje tylko i az problem synchronizacji dancyh pomiedzy n serwerami. tyle pokazala wyrocznia apt-cache search high availability pen - Load balancer for "simple" tcp based protocols pen works for tcp based protocols such as http or smtp. It allows several servers to appear as one to the outside and automatically detects servers that are down and distributes clients among the available servers. This gives high availability and scalable performance. tra - a file-system synchronize However, Tra is still in early development. It doesn't yet have a GUI interface, the command-line interface is still evolving, there is no support for Windows hosts, and it has received only limited testing. Meanwhile, this package is meant to facilitate testing and development of Tra. wiec moze sies nie nadawac unison - A file-synchronization tool for Unix and Windows moze ograniczac skalowalnosc - synchronizuje tylko pomiedzy dwoma wezlami (jak zrozumialem z opisu) drbd - RAID 1 over tcp/ip for Linux utilities ipvsadm - Linux Virtual Server support programs The Linux Virtual Server is a highly scalable and highly available server built on a cluster of real servers. The architecture of the cluster is transparent to end users, and the users see only a single virtual server. ... Jezeli wydajnosc nie jest problemem, to moze lepiej zainwestowac w dobry serwer ktorego awaryjnosc jest akceptowalna, anizeli konstruowac klastry, ktorymi chyba trudniej zarzadzac? ( pozostaja jeszcze wzledy ekonomiczne) Jezeli ktos mialmy ochote i zasoby i chcialby przetestowac/udostepnic do testowania ktores z rozwiazan z pokazywanych przez apt-cache search high availability # (sid main contrib non-free) - czyli powinnismy dostac mniej wiecej to samo to jestem za -- Bartosz Hetmanski
Re: Cluster
Użytkownik Marcin Owsiany napisał: On Sun, Apr 25, 2004 at 09:41:57PM +0200, Gasior wrote: Podstawowym wymaganiem jest wiec, aby niezaleznie ile serwerow dziala w tym momencie, uzytkownik koncowy mial dostep do uslug. W przypadku padu ktoregos serwera, pozostale przejma jego "obowiazki". Skoro chcesz mieć trzy warstwy, a w każdej redundancję, to jakby nie liczyć wychodzi conajmniej sześć maszyn. Jeśli chcesz się zmieścić na mniejszej ilości, musisz któreś warstwy połączyć, albo z (redundancji w) którejś zrezygnować. Marcin Idealne byloby dla mnie takie rozwiazanie, zeby serwery na ktorych dzialaja uslugi dzielily w jakis sposob dyski. Zapis moglby nastepowac na obojetnie ktorym z nich i widoczny bylby na pozostalych. Z tego co znalazlem na sieci to istnieja jedynie rozwiazania, gdzie jeden z serwerow jest masterem, drugi synchronizuje sie z niego. W przypadku padu mastera, zamieniaja sie miejscami. Tak konfiguracja nie balansuje jednak ruchu, poniewaz zazwyczaj pracuje sam master, a drugi serwer "czeka" na jego pad. Synchronizacja przez rsync i pochodne raczej odpada, zakladam bowiem ze w ciagu dnia moze byc sporo zmian na dysku (mail, ftp itp.). Czy jakas macierz dyskowa podlaczona do LAN'a, nie rozwiaze problemu wspoldzielenia dyskow? Sa tez chyba macierze SCSI<->SCSI, do ktorych mozna podlaczyc kilka serwerow, tylko nie moge dobic sie do ich cen (pewnie kosmos). Jakby nie patrzac wychodzi najmniej trzy maszyny (router, storage i "real server"), tylko w takim przypadku lepiej chyba rozmiescic poszczegolne uslugi na roznych serwerach. -- Maciej Gasiorowski
Re: Cluster
On Sun, Apr 25, 2004 at 09:41:57PM +0200, Gasior wrote: > Podstawowym wymaganiem jest wiec, aby niezaleznie ile serwerow dziala w > tym momencie, uzytkownik koncowy mial dostep do uslug. W przypadku padu > ktoregos serwera, pozostale przejma jego "obowiazki". Skoro chcesz mieć trzy warstwy, a w każdej redundancję, to jakby nie liczyć wychodzi conajmniej sześć maszyn. Jeśli chcesz się zmieścić na mniejszej ilości, musisz któreś warstwy połączyć, albo z (redundancji w) którejś zrezygnować. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Cluster
Użytkownik Przemysław Maciuszko napisał: On Sun, Apr 25, 2004 at 07:54:05PM +0200, Gasior wrote: Stanalem w pracy przed zadaniem zaprojektowania wydajnego systemu pod potrzeby hostingowe, opartego oczywiscie na Debianie i rozwiazaniach OpenSource. To może napisz coś więcej o tych wymaganiach? Dotychczas dzialalo to w ten sposob, ze na jednym serwerze postawiony byl Apache z wirtualkami, na drugim serwer pocztowy. To w sumie dzialalo, tyle ze mialo ta wade, ze jak padl jeden serwer to nie bylo dostepu do jakiejs uslugi. Teraz system jest projektowany od nowa, wiec chcialbym uniknac powyzszej sytuacji. Podstawowym wymaganiem jest wiec, aby niezaleznie ile serwerow dziala w tym momencie, uzytkownik koncowy mial dostep do uslug. W przypadku padu ktoregos serwera, pozostale przejma jego "obowiazki". Uzytkownik koncowy zauwazy najwyzej spadek wydajnosci, ale dostep do uslugi bedzie mial zapewniony. -- Gasior.
Re: Cluster
On Sun, Apr 25, 2004 at 07:54:05PM +0200, Gasior wrote: > Stanalem w pracy przed zadaniem zaprojektowania wydajnego systemu pod > potrzeby hostingowe, opartego oczywiscie na Debianie i rozwiazaniach > OpenSource. To może napisz coś więcej o tych wymaganiach? -- Przemysław Maciuszko Agora SA
Cluster
Witam wszystkich. Stanalem w pracy przed zadaniem zaprojektowania wydajnego systemu pod potrzeby hostingowe, opartego oczywiscie na Debianie i rozwiazaniach OpenSource. Oczywiscie system ma byc jak najbardziej niezawodny i dostepny. Jednym z rozwiazan jest zastosowania klastra. Zrobilem rozeznanie w rodzajach klastrow i technologiach ale zwracam sie o pomoc do specjalistow :), aby spojrzeli na to co wymodzilem i ewentualnie naprowadzili mnie na lepsze rozwiazanie. Podstawowe uslugi dostepne dla uzytkownikow: WWW, MAIL (smtp, pop, imap), MySQL, FTP. Oprocz tego musi tam dzialac LDAP (do obslugi kont pocztowych) niedostepny na zewnatrz. Caly system ma dzialac na takiej zasadzie, ze obojetnie do ktorego wezla sie nie podlacze, moge skorzystac z kazdej uslugi i mam dostep do tych samych danych. Ma to zapobiec sytuacji w ktorej wysiada jeden z serwerow i nie mamy dostepu do jakiejs uslugi. Moj pomysl: 1. Serwer backend'owy z macierza dyskowa - tu umieszczone beda wirtualki klientow, bazy danych i skrzynki pocztowe. Wydaje mi sie, ze ten punkt systemu nalezaloby zdublowac poniewaz jest to punkt krytyczny. Tu najbardziej pasowal mi hybrid cluster + DRBD do replikacji danych. 2. Węzły klastra - na tych serwerach uruchomione będą usługi dostępne dla klientów. Dane podmontowane będą przez NFS z serwera backend'owego. 3. Serwer zarzadzajacy ruchem (LVS) - ten serwer "wystawiony" jest w internecie i przyjmuje wszystkie polaczenia. Nastepnie kieruje polaczenia do najmniej obciazonego serwera z punktu 2. To rowniez jest punkt krytyczny calego systemu, wiec nalezaloby go zdublowac. Z tego projektu widac, ze potrzeba co najmniej 4 serwery na zarzadzanie dyskami i balansowanie ruchu. Do tego dochodza co najmniej dwa (lub wiecej) jako wezly klastra. Problem z tym ze mam do dyspozycji 3 max 4 maszyny, a chcialbym rozwiazac to w sposob umozliwiajacy latwa rozbudowe systemu jak bedzie taka potrzeba. Mam nadzieje, ze znajdzie sie ktos chetny do podjecia dyskusji. Chodzi mi tutaj bardziej o sama idee dzialania takiego systemu, niz konkretna konfiguracje (o tym juz sobie doczytam). Za wszelkie pomysly z gory wielkie dzieki. -- Gasior.
