cyberluk

Tak, dl360. Np. prosty ubench pokazuje juz wyniki o 40% lepsze od zegarowo takiego samego p4. Czym testowales wydajnosc ? Bo wydajnosc jednej aplikacji, a wydajnosc w srodowisku multi-user to dwa swiaty. pozdr. A to ja doskonale wiem Ogólnie nie uznaje benchmarków. Są zbyt syntetyczne. Ja testowałem na kilka sposobów - jeden z nich to baza danych MySQL. Łącznie 60GB na dysku. Rekordów w tej chwili nie pamiętam - jedna tabela wiem, że rzuciła mnie na kolana - ~19mln rekordów. Maszyny do konkursu: - 2x PIII-S 1400MHz + 2GB RAMu + 4xdyski SCSI 15k obr/min + RAID 10 wspomniany Dellik 2550 - 1x P4 3.0Ghz + 2GB RAMu + 4xdyski SATA WD Raptor 10k obr/min 72GB + RAID 10 - składak według mojego pomysłu. Do tego 16 komputerów P4 2.4GHz 2GB RAMU + soft oraclowy do symulowania poruszania się po sklepie internetowym odpalone na każdym komputerze. Łącznie symulowanych 512 klientów. Wszystko połączone Gbitem na Ciscowym switchu. Soft jest o tyle fajny, że sam sobie losowo generuje ścieżki podążania po sklepie. Nie jest to tak idealne jak użytkownicy, ale bardzo zbliżone. Obie maszyny były specjalnie zoptymalizowane pod kątem wydajności MySQL'a - różnic jest sporo. Ogólnie P4 wyszło duuuużo lepiej, ale dopiero jak usunięty została podstawowy problem - chłodzenie procesora. Tak wydajność była tragiczna. Inna sprawa, że to jest charakterystyczne zastosowanie i nie tylko moc procesora się liczyła... Przy benchmarku Zeusa było już tylko około 15% przewagi dla P4. Przepaść się zrodziła dopiero, jak zaprzęgnąłem do pracy Opterony i Xeony PIII są ogólnie bardzo przyjemne jeżeli chodzi o moc matematyczną, ale brakuje im sporo w zastosowaniach, gdzie potrzebna jest duża przepustowość pamięci i poszczególnych magistrali.

Sorki, że robię mały off-topic, ale mógłbyś się pochwalić jakież to maszyny macie? Dalej HP DL360 na PIII-S albo inaczej Tualatinkach? Bo jeżeli tak, to ciekawe jest to co piszesz Mam pod biurkiem Dellika 2550 i jakoś mój "desktop" z P4 jest sporo wydajniejszy Pod każdym względem... Bez urazy - to nie ma być atak, tylko jestem ciekaw jakim cudem wychodzi Ci "szybciej". Możemy się przenieść do innego wątku, żeby tutaj nie śmiecić.

Mainframe ma po prostu "procesor", a co jest pod spodem, to już sprawa techników (a jest tam kilkanaście modułów z Power5). Capacity on Demand nie dotyczy Mainframów. Ta technologia została użyta w iSeries i OpenPower. Mainframe jest szyty na miarę i potrzeby klienta z uwzględnieniem zapotrzebowania na moc na kilka lat. Mainframe to tylko seria zSeries lub stara s/390. Działa pod kontrolą OS/390, który dawał 16 partycji sprzętowych, lub nowszym na zSeries zVM, który pozwala stworzyć 65k partycji/wirtualnych maszyn Dodatkowo wydajność procesora MF jest liczona w MIPSach, ale są to złożone instrukcje np Fortrana, a nie MIPSy znane ze świata PC. Przy portowaniu Linux'a jednym z problemów było przystosowanie kernela do wykonywania wielu prostych operacji w ramach jednej skomplikowanej wykonywanej przez główny procesor. Z ciekawostek można jeszcze powiedzieć, że celem do którego się dąży zawsze przy wyliczaniu mocy mainframe, jest utrzymywanie obciążenia procesora na poziomie 90%. Dzieje się tak dlatego, że jest to najdroższa część systemu i musi być efektywnie wykorzystana Jeżeli chodzi o Capacity on Demand - bardzo ładnie to działa na iSeries + SUSE + Oracle. Szykowałem kiedyś takie demo na LinuxTechshare z chłopakami z IBM Innovation Center... Cudo

Mainframe jest raczje ekstremum, ze względu na koszty rozwiązania. Elastyczność. Cóż... Tutaj nie trzeba się martwić o brak mocy czy zestarzenie się technologicznie maszyny w przeciągu 5 czy 10 lat... Przy NBD maszyna przyjedzie do 24 godzin od zgłoszenia awarii. Z doświadczenia wiem, że HP są podstawiane max w 3 godziny od telefonu. Ja akurat miałem w swoim życiu doświadczenienie z mainframami IBM'a i są to czasy, które do końca życia zapamiętam. To jest zupełnie inny świat. Uptime maszyny na poziomie 12 lat to jest normalka. Każdy komponent jest przynajmniej zdublowany, a administratorzy mainframe, żeby go wyłączyć normalnie, muszą sięgnąć do książki, bo takiej procedury się po prostu nie pamięta. Dwoje administratorów MainFrame, z którymi miałem przyjemność pracować, w swojej 40 letniej kerierze nie musiało ani razu tej maszyny zdołować. Z ciekawostek dodam, że do zarządzania takim cudem, 3 lata temu IBM dokładał dwa notebooki t43 o wartości 16tyś zł każdy W końcu konsola też musiała być redundatna... A jeżeli chodzi o wydajność - dostałem na kilka dni jedną partycję - 8GB RAMU i czas procesora na poziomie 30% głównego procesora, ale z niskim priorytetem, żebym nie zwalniał innych partycji/aplikacji. Dla testu zaimportowałem 250k rekordów do bazy Postgres. Zajęło to 2 sekundy Długo zbierałem moją szczękę z podłogi...

Trzeba znaleźć złoty środek - jak zawsze, chociaż to będzie trudne. Drobne rozmyślania: Tanie serwery: + są tanie + jest ich dużo - w przypadku awarii jednego, na serwerze znajdzie się mniejsza ilość klientów dotkniętych awarią - zazwyczaj są wiekowe - sprzęt się psuje - mała odporność na piki obciążenia - na mocniejszym serwerze łatwiej zbuforować nagły przyrost ruchu - więcej płacimy za miejsce - więcej pracy do zarządzania nimi, chociaż to jest punkt sporny - większe ryzyko, że coś nawali Drogie serwery: + jest ich mało - mniejsze koszty utrzymania + są nowe - mniejsze ryzyko awarii + zazwyczaj wymiana maszyny Next Buisness Day + większa odporność na piki obciążenia, a w niektórych przypadkach - brak jakichkolwiek obaw o zbyt małą moc serwera + mniej pracy przy zarządzaniu + małe ryzyko, że coś padnie - są drogie - jest ich mało -> mają więcej klientów -> większy impakt w czasie awarii Fajnie widać, że oba rozwiązania są dokładnym przeciwieństwem. Cały trick polega na tym, żeby balansować wiek serwera - jego cenę - jego wydajność. To jest tak naprawdę najważniejsze przy projektowaniu i rozwijaniu takiej platformy. Padają tutaj stwierdzenia o load balancingu itp itd. Tylko trzeba sobie zdawać sprawę o ile powiększamy koszty takiego rozwiązania - zdublowany load balancer, zdublowana sieć, itp itd. Inaczej to co ma ratować nas przed awariami, staje się (jak to ładnie brzmi) Single Point of Failure. Jak do tej pory najbardziej optymalne rozwiązanie ma chyba home.pl - w miarę tanie serwery + duża ich ilość + w razie padu serwera odpalany chroot na backupie (wyczytać można z pdf'a z którejś konferencji). No chyba, że ktoś ma bogatego wujka I stać go na profesjonalne zabawki - Cisco, Juniper, Zeus, Sun, Veritas

Nie wszedzie;) Na kablówce (czyt. jakies dsl od tepsy:P) nie dziala. Pewnie zaraz zacznie, jak się nowe trasy rozpropagują. U mnie nie działało przez chwile, później ruszyła strona główna home.pl, ale nie działały strony klientów. Minutę później ruszyły strony klientów.

Widać, kto ma prawdziwego BGP'a

hmm 6MBx50000 to jest 300 000MB a to jest 300GB, a nie 3 TB, co zmienia trochę wycenę. Dyski SATA+RAID z zapasem na 500GB - aż tak tragicznie nie wyjdzie. Zgoda - żadne pudełka z linuxem. Polecam Netscreen/Juniper Dobry kontroler SATA + dobre dyski SATA i nie będzie różnicy SCSI/SATA, a w kieszeni zostanie sporo gotówki. Chyba bardzo duży Tak na oko to z 35k wyjdzie Kupując badziewne HP. Jeżeli już kupować sprzęt swój, to może faktycznie pomyśleć nad propozycją która już tu padła - IBM iSeries, ale w wersji OpenPower - maszynkę można złożyć za ~6000USD, a jej moc będzie porażająca No i ponieważ nie masz kasy na zdublowanie wszystkiego, to ja bym jednak polecał jedną mocną maszynę + jakaś technika wirtualizacji: - na x86 - Xen - na OpenPower - tam jest z założenia menadżer partycji sprzętowych

sorry, ale proponuje przeczytac jeszcze raz ze zrozumieniem gdzie ty tam widzisz 1200 routerow ? "Juniper M-series and Cisco GSR 1,2000 routers work in partnership at 1&1 to make a definitive statement in network routing" - chyba, że mają literówkę i to ma być GSR 12000, co też jest prawdopodobne. Napiszę do nich maila i się wyjaśni. PS. To jest literówka na 100% - bo nawet gdyby, to by było 12k routerów My mistake, ale tak to jest jak się śpi przez tydzień po 45 minut

A kto mówi, że to musi być jeden kabel Popatrz tutaj: Klik! 38k serwerów w jednym DC + 5,6MW klimatyzacji, do tego 1200 routerów sporych i nawet są w stanie uciągnąć to wszystko na dieslach. Przecież do takiego DC idzie zasilanie z kilku stacji transformatorowych... Nie musisz mieć jednego kabla... Nawet w centrum Warszawy masz dwa DC - jedno z nich ma dwa piętra po 240 szaf 42U + osprzęt typu klimatyzacja - na każdą szafę liczone jest 20A, co ci daje 9.6kA na sam sprzęt. A klima? No i to jest małe DC Wydaje mi się, że zasilanie takiego DC to nie jest wielki problem.

Jeżeli funkcja jest podatna na DoS, to zazwyczaj jest wina to kompilatora, który generuje zły kod, albo - zła implementacja funkcji w bibliotece (jeżeli lib'y są binarne). Na dokładnie takim samym poziomie podatne może być C, Perl, PHP czy Java. Nie oszukujmy się - większość błędów wynika z błędnie napisane kodu, a co za tym idzie z błędnie wykorzystanych funkcji danego języka (to jest co innego niż błędy w samej fukncji). Jeżeli chodzi o PHP i C to chodziło mi o: - szybkość pisania kodu C vs PHP - złożoność kodu C vs PHP - wydajność tego kodu C vs PHP Jedyna wspólna cecha, to łatwość popełnienia błędów w obu tych językach - chociaż błędy te będą zupełnie innego typu B) Nie róbmy już OT Kolega pytał o rozwiązanie i to zostało mu podsunięte

O, to moja już przestała B) Teraz już zna RFC. A tak poważnie to ja ten etap przechodziłem z 3 lata temu... Już się na szczęście wyleczyłem Od momentu kiedy mam dostęp do fajnych zabawek, zrozumiałem, że to nie dane rozwiązanie należy dopasować do sprzętu - to sprzęt ma służyć realizacji danego projektu Z mojej strony życzę tego wszystkim O wiele lepiej się wymyśla nowe rozwiązania. A co do OpenBSD - i tak "jego ojciec" jest lepszy

A może _tu wstaw język programowania_ + SOAP + SUDO jako serwer poleceń dla panela. Do tego panel napisany też w _tu wstaw język programowania_? Tak będzie stabilnie i bezpiecznie - wymyślanie swojego protokołu do komunikacji panel<->daemon przez kogoś kto się uczy programować z założenia jest chore B) Jak już robić, to porządnie. No i starałbym się jak najwięcej funkcji napisać samemu po stronie daemona np. odczytywanie uptime nie na zasadzie pipe>bash>uptime i parsowanie, tylko wyciągnięcie z odpowiedniego miejsca informacji i odpowiednia prezentacja. I dlaczego nie PHP? Sorry, ale błędy w oprogramowaniu wynikają z braku umiejętności programisty, a nie wad języka. Źle napisany kod w C, Perlu czy PHP będzie dokładnie tak samo szkodliwy. Różnica polega na prostocie i szybkości pisania - skrajne przypadki PHP vs C... Ja bym proponował pisać oba moduły w PHP, ale... no właśnie zwracając uwagę na _bezpieczne_ programowanie!

Z tego co wiem jest - ja mam np w trakcie dyżuru 1/8 stawki godzinowej jak nic nie robię, a jak podejmuję interwencję, to zależnie od pory dnia, tygodnia itp 100, 200 lub 300% stawki godzinowej.

Wbrew pozorom nie Tym bardziej, że dzień sobie sam wybierałem Tu chodziło o specyficzną sprawę pomocy w konfiguracji klientów, które działały na tym serwerze. Jak zrobiłem dobrego manuala, to praktycznie w ogóle nie musiałem siedzieć.

Tak, tak - doczytałem. Raczej chodziło mi o to pytanie do rusela Ja ci mogę podsunąć przykład mojej osoby - jako dodatkowe zajęcie zajmowałem się serwerem dla jednej firmy. Maszynę mi dali, wstawili do serwerowni, ja miałem zainstalować system, opiekować się nim, i być dostępny pod mailem 3 razy w tygodniu od 20-21. Projekt trwał rok, może będzie trwał dalej Kasowałem 1500 zł netto za miesiąc po znajomości (czytaj: mniej niż normalnie).

Sorry, że zrobię mały OT, ale jaką ty widzisz pensje dla administratora? Bo albo te remote-hands są strasznie drogie, albo ten administrator mało zarabia

Nie będzie - operacje na adresowaniu 64 bitowy i rejestrach 64 bitowych trwają dłużej/są wolniejsze. Weź sobie Sparca. Chodzi w trybie 64bit i 32 bit. Ten 64bit jest o jakieś 10% wolniejszy. Plusem architektury 64bit jest adresowanie pamieci. Koniec z limitem 4GB RAMu, podziałem pamięci na lowmem i highmem, ograniczeniem wielkości procesu. Jeżeli nie masz 4GB lub więcej - odpuść sobie 64bit. Chyba, że będziesz miał na tej maszynie np bazę danych, która zajmuje 3GB, to wtedy nawet dla 4GB RAMu opłaca się postawić kernel 64bit... Jeżeli chodzi o kompatybilność - tak na debianie 64bitowym da się uruchomić soft 32bit ale nie w prost! Musisz przygotować całe środowisko z libami dla aplikacji. Kernel musi mieć wkompilowaną obsługę "emulacji" 32bitów. Domyślny w Debianie ma.

10Mbit z podziałem 2Mbit do TPSA reszta do pozostałych sieci - 270 zł netto za 1Mbit. Cena taka tylko dlatego, że był do podciągnięcia nowy światłowód. Normalnie 250 zł. Łącze z GTS. Ogólnie zawsze TPSA kopie po tyłku... Na szęście po ostanich negocjacjach zostali zmuszeni do obniżenia cen łącz międzyoperatorskich nawet o 20%

Hej, Przeglądjąc forum bardzo często, a właściwie zawsze pada stwierdzenie typu "dobry support", "kiepski support" itp. To jest tylko stwierdzenie. Tak z czystej ciekawości - co rozumiecie pod pojęciem "support"? Czy macie na myśli pytania związane z działalnością serwera? Czy może rozwiązywanie problemów użytkownika z jakimś oprogramowaniem? Czy może odpowiadania na pytania użytkownika, któremu coś nie działa, bo nie potrafi, ale wydaje mu się, że jest to wina providera? Wiem, że się czepiam (kolejny raz - patrz "Koszty prowadzenia hostingu") Ale to pewnie przeżycia sprzed kilku lat i odbite piętno na mojej psychice po świadczeniu supportu dla pewnej grupy użytkowników Pozdrawiam, Łukasz Walkowski PS. Czemu forum zamieniło pierwsze literki w temacie na wielkie?

Tak jak podejrzewałem, pojawiły się dwa różne rodzaje pojęcia supportu - może nie jest to dokładnie odzwierciedlone w ilości postów, ale jednak podział istnieje. Co było przyczyną powstania tego topicu? Jak już napisałem doświadczenie. Tak się składa że dobrych kilka lat temu oferowałem pewną usługę. Starałem się świadczyć jak najlepszy support, czyli właśnie odpowiadać na wszystkie pytania w sposób łatwy i czytelny. Bardzo szybko okazało się, że klienci podchwycili temat i... Miałem przekichane. Telefony w środku nocy w święta z rzeczami których wogóle nie powinienem dotykać (np. kompilacja i konfiguracja jakiegoś softu, żeby klient mógł tylko sobie go używać). Szybko stało się jasne, że sam nie dam rady i potrzeba było ludzi. Ponieważ były to czasy polpaka-t 2Mbit za 3000 zł miesięcznie, to ludzi którzy za darmową usługę lub (to już wogóle był szok) podciągnięcia "kawalka rurki" do domu będą sie zajmować pomocą było trochę. Powstał specjalny portal z dokumentacją, kreatorami, FAQami itp itd (zajmował około 300MB samej dokumentacji). I co? TO NIC NIE POMOGŁO. Dochodziło do takich paranoi, że byle powód był dobry, żeby dzwonić po support, coś w stylu "Mama mnie okrzyczała!" - telefon do administratora. I to wszystko za 100 zł netto (25 Euro) rocznie... Później przyszła praca w dość dużej firmie i stałem się "Inżynierem Systemowym". Częściowo do moich zadań należało supportowanie problemów klienta, z którymi on sam nie mógł sobie dać rady czy po prostu nie potrafił. Oczywiście musiał mieć wykupiony kontrakt na rok i płacił za każdą godzinę mojej pracy - ile? 800 Euro za godzinę to była stawka wyjściowa, bardzo często negocjowana do ~200Euro. Kontrakty startowały od 2000 Euro netto rocznie, za taką ilość zgłoszeń, którą niektórzy wykorzystują w tydzień. Wydawało mi się, że coś jest nie tak, że coś jest za drogo. Okazało się, że moja żona ma stawkę godzinową na poziomie 150 - 200 Euro za godzinę. Różnica polegała tym, że ja się zajmowałe serwerami, które musiały działać i przestój dobowy to była ciężka sprawa dla firmy. Ona zajmowała się bezpieczeństwem i telekomunikacją. Później dowiedziałem się, że najniższa cena supportu MS stała na poziomie 100Euro za godzinę. Oczywiście szczególnym przypadkiem jest dzierżawa inzyniera systemowego na rok - 400.000 Euro Dlaczego o tym piszę? Chodzi mi o uświadomienie co niektórym, że support jest drogi, administratorzy powinni się zajmować administracją systemami i ich rozwojem, a nie odpowiadaniem na pytania klientów jak to ma miejsce w większości "low-budget" hostingów. Dlaczego? Po pierwsze i najważniejsze - ADMINISTRATORÓW MUSI BYĆ WIĘCEJ NIŻ JEDEN. Nie ważne czy jest jeden serwer czy dwa czy 5. Zastanawiał się ktoś co będzie jeżeli administrator zachoruje, będzie miał wypadek, czy (nikomu nie życzę) umrze? No właśnie... Po drugie - administrator jest za drogi i zbyt ważny żeby bawił się w support dla klienta i jeszcze pisał mu poradniki jak coś ma zrobić. Lepiej zatrudnić ze dwóch studenciaków ze średnią znajomością systemu na którym stoi platforma i oni będą rozwiązywać problemy za 1000 zł netto miesięcznie, a nie 2500 netto miesięcznie. W przypadkach krytycznych sprawa przesunięta do administratora... Jeżeli będzie ich dwóch, mogą obsługiwać szeroki zakres czasu supportu - no od 8 do 16, a drugi od 14 do 22... Częściowo czas się pokryje i będą mogli rozładować ewentualne kolejki zgłoszeń. Po trzecie - ciągła bieganina od supportu do systemu jest demotywująca... Nie robi się dobrze, ani jednego ani drugiego... Nie twierdzę, że supportu nie może istnieć w tanim hostingu. Owszem, ale ile taka osobe wytrzyma psychicznie? Rok, dwa lata? Do tego dochodzi jeszcze ciągłe jeżdżenie po administratorach (na tym forum najwięcej ), że nie można się dodzwonić w czasie awarii, że nie odpowiedzieli w ciągu 5 minut... Jeżeli jest awaria administrator stara się ją usunąć, a dzwonienie tylko mu przerywa. Wydawać by się mogło, że 'e tylko ja zadzwonie', ale tak może pomyśleć 300 osób! I co? I zamiast naprawiać system będzie siedział przy telefonie... I tutaj też by się przydał studencik OK, wystarczy na koniec kilka małych próśb: - jeżeli jest awaria - dajmy administratorowi pracować w spokoju - chyba że się przedłuża i nie ma żadnych informacji o tym co się stało - nawet wtedy dajmy mu z 10 minut. - argumenty płacę to wymagam wsadźmy między książki - opłata 200 zł (50 Euro) za hosting rocznie nie pozwala na świadczenie supportu z SLA 5 minut - bądźmy realistami - to są ludzie nie maszyny. Należy odróżnić staranie się i przypadki, że tak szybko odpowiedź uzyskamy od normalności. Mogę się założyć, że zalanie któregoś hostingu 40 pytaniami o jakieś detale wymagające zerknięcia do systemu/bazy spowoduje, że czas odpowiedzi znacznie się wydłuży - nie jeździjmy wtedy po hostingu/administratorze - zadawajmy pytania w sposób jasny zrozumiały, popraty logami/zrzutami ekranu - to ułatwia pracę przy supporcie - nie nazywajmy administratora informatykiem - to dwie różne bestie - bądźmy ludźmi i zrozumny, że niższ cena == niższa jakość Może to trochę głupie co napisałem, ale mam 10 lat stażu administratora i po prostu jest mi szkoda wszystkich innych kolegów po fachu, bo wiem jak powinna wyglądać ich praca, a jak często wygląda... Nikogo nie chciałem obrażać - jeżeli ktoś tak się poczuł - sorry. Całość miała naświetlić i uświadomić problem który występuje od zawsze i będzie wystepował, a od nas będzie zależała skala tego zjawiska.

1. To nie wątki Apache 2 też może chodzić na wątkach a daaaaleko mu do takich osiągów. 2. mod_rewrite nie jest kompatybilny z Apachowym 3. VirtualHosty bardziej skomplikowane wcale nie są takie banalne - trzeba się bawić w regexp'y i cały config pocięty jest if'ami. 4. Największa wada, której do tej pory (od wersji 1.3.x) nie udało się usunąć to brak reload'a - trzeba restartować serwer, co powoduje zerwanie wszystkich połączeń... Ale ogólnie zapowiada się ciakwie Aha no i benchamrki na stronie są nazbyt optymistyczne przy produkcyjnym środowisku...

Oczywiście. Całkiem niedawno z corowymi developerami SUSE bardzo intensywnie walczyliśmy z problemem HT i kernela. Przez kilka miesięcy różnego debugowania, testowania i sprawdzania została opracowana łatka która sprawuje się najlepiej - tzn jest uśredniona. Jakie problemy się pojawiały? Np takie, że jak kernel był zoptymalizowany dla MySQL (przyrost wydajnośći od 8-17%), to Apache zwalanił nawet o 32%. Jeżeli podkręciło się apache'a w wersji wątkowej, to wersja procesowa leciała na łeb na szyję. I tak można wymianiać dużo, ale skoro to jest forum o hostingu zostańmy przy tych. Co ciekawe podobne zależności zauważyłem we FreeBSD i NetBSD. Prawda jest taka, że HT został zrobiony pod Windowsa i tam sprawdza się najlepiej. Prawda też jest taka, że systemy z włączonym HT chodził znacząco krócej niż bez na tych samych prockach - serwer który miałem do testów właśnie na SUSE chodził 248 dni pod pełnym obciążeniem bez HT (został zreebotowany bo więcej nie było sensu) w przeciwieństwie do 74 dni z HT (totalny zwis).

To i ja dorzucę swoje 5 gr. Po pierwsze AMD nie jest złe o ile mówimy o procesorach pod serwer (opteron). Dla odmiany HT i Linux to dwie różne rzeczy. Więcej psuje niż pomaga. Tak samo pomyłką są procesory dual-core pod serwer - niestety ograniczenia tej architektury powowdują, że zamiast skalować się liniowo, wzrost wydajności jest tylko o około 60%. Dysk ATA na serwer to też nie jest dobry pomysł. Od tygodnia leży u mnie maszyna w której było 8 dysków Maxtora 250GB SATA podpiętych pod 3ware 8506-12. Nie pochodziły rok czasu i... posypały się 3 z nich. Jak można sie domyślić - RAID5 sobie nie poradził. Wynalazki takie jak SLI oznaczają płytę desktopową, która do zastosowań stricte serwerowych ma się nijak. Nie wiem ile taki sprzęt będzie kosztował, ale według mnie rozglądnij się za słabszym sprzętem ale z prawdziwym serwerem. Do dzisiaj mam taką fajna płytę główną ASUS CUR-DLS na serverworksie, która kiedyś kosztowała 2500 zł. I co? Efekt jest taki że mam 2GB RAMu, 2xPIII 800 i zapomniałem, że mam serwer. Zero problemów. Aha no i oczywiście SCSI. Sprzęt serwerowy to jest zupełnie inna bajka i jeżeli chodzi o wydajnośći i stabilność, więc zastanów się 5 razy zanim kupisz... cyberluk

Pytanie podstawowe - system, który ja chcę mieć zainstalowany, czy jakaś domyślna instalkę czegoś w stylu Debian, RedHat, SuSE? Bo tak się składa, że jeżeli już bym miał stawiać to na swojej, przerobionej od podstaw dystrybucji NetBSD...