W dniu 20.02.2013 14:53, MK pisze:

Witam

Zamierzam zakupic dwa serwery (na motor bazy danych i oprogramowanie ERP)
oraz do nich dedykowana macierz dyskowa.
Chodzi mi o to w jaki sposob obecnie nalezy spiac takie serwery do wspolnej
macierzy dyskowej. W macierzy beda dyski SAS 15krpm po 300GB w RAID 5.
Czy zakupic karty i macierz z portami Fiber Channel czy wystarczy miec 2
gniazda SAS w serwerach oraz 4 w macierzy (redundancja) aby zapewnic
szybkosc operacji I/O pomiedzy serwerami a macierza?

Jeszcze pytanie jaki masz budżet oraz jakie są rzeczywiste potrzeby tego systemu.

W praktyce może się okazać, że Twoje potrzeby dźwignie współczesny "domowy" pecet na dyskach SATA za ułamek ceny. I to z drugim identycznym zapasowym. I jeszcze zostanie nieco mocy i miejsca na jeszcze kilka wirtualnych maszyn na np. serwery pocztowe czy www.

--
Świadomie psujący kodowanie i formatowanie wierszy
są jak srający z lenistwa i głupoty na środku pokoju.
I jeszcze ci durnie tłumaczą to nowoczesnością...

Tak z ciekawostek: profesjonalny serwer z wypasionymi dyskami SAS 15krpm - ciągły transfer z dysku do /dev/null to jakieś 130MB/s. Ten sam test na "domowym" pececie (płyta sabertooth) z "zielonymi" dyskami WD (SATA) chodzącymi w mirrorze - ponad 90MB/s (i to mimo tego, że na tej samej programowej macierzy chodzi kilka serwerów, włącznie z dyskiem sieciowym, oraz kilka wirtualnych urządzeń sieciowych, a ten SASowy jest golutki)

Tak, wiem, przy zapisie będzie dużo gorzej i nie mierzę czasu dostępu do danych tylko ciągły transfer (około gigabajta).

Ale to tylko taka ciekawostka :)

Dnia Wed, 20 Feb 2013 22:57:05 +0100, Andrzej Lawa napisał(a):

Tak z ciekawostek: profesjonalny serwer z wypasionymi dyskami SAS 15krpm - ciągły transfer z dysku do /dev/null to jakieś 130MB/s. Ten sam test na "domowym" pececie (płyta sabertooth) z "zielonymi" dyskami WD (SATA) chodzącymi w mirrorze - ponad 90MB/s (i to mimo tego, że na tej samej programowej macierzy chodzi kilka serwerów, włącznie z dyskiem sieciowym, oraz kilka wirtualnych urządzeń sieciowych, a ten SASowy jest golutki)

Tak, wiem, przy zapisie będzie dużo gorzej i nie mierzę czasu dostępu do danych tylko ciągły transfer (około gigabajta).

Ale to tylko taka ciekawostka :)

Ciągłe transfery są mało istotne, pomierz raczej IOPs. Zresztą, o czym
my w ogóle mówimy - człowiek chce postawić przyzwoite środowisko ERP pod
x użytkowników, a nie jakiś serwerek do kompilacji apek...
--
M.   /odpowiadając na priv zmień px na pl/

W dniu 21.02.2013 00:50, Michal Kawecki pisze:

Ciągłe transfery są mało istotne, pomierz raczej IOPs. Zresztą, o czym
my w ogóle mówimy - człowiek chce postawić przyzwoite środowisko ERP pod
x użytkowników, a nie jakiś serwerek do kompilacji apek...

Przyzwoite powinno w miarę efektywnie wykorzystywać sprzęt, a x to może
być 50, ale może też być 5000...

--
Świadomie psujący kodowanie i formatowanie wierszy
są jak srający z lenistwa i głupoty na środku pokoju.
I jeszcze ci durnie tłumaczą to nowoczesnością...

Dnia Thu, 21 Feb 2013 08:58:48 +0100, Andrzej Lawa napisał(a):

W dniu 21.02.2013 00:50, Michal Kawecki pisze:

Ciągłe transfery są mało istotne, pomierz raczej IOPs. Zresztą, o czym
my w ogóle mówimy - człowiek chce postawić przyzwoite środowisko ERP pod
x użytkowników, a nie jakiś serwerek do kompilacji apek...

Przyzwoite powinno w miarę efektywnie wykorzystywać sprzęt,

Środowisko musi być też niezawodne, tj. zapewniać możliwość podjęcia
dalszej pracy natychmiast po awarii pojedynczego hosta w klastrze, a nie
dopiero po odtworzeniu maszyny z backupu. Tj. ja wiem, że teoretycznie
da się to zrobić na dwóch synchronizowanych przez sieć pecetach, ale ani
to niezawodne, ani wydajne, ani elastyczne... Ale w sumie to trochę
spekulacje, bo nie znamy oczekiwań wątkotwórcy.

a x to może
być 50, ale może też być 5000...

Tego jeszcze nie wiadomo, ale skoro człowiek pyta o podstawy, to pewnie
chodzi o jakieś rozwiązanie stawiane własnymi siłami, bez pomocy firmy
wyspecjalizowanej w budowaniu środowisk ERP. Ergo - dla max 20-30
userów. W przeliczeniu na usera koszty takiej serwerowni będą bardzo
wysokie, stąd była moja sugestia rozważenia kolokacji. Poza tym są firmy
prowadzące za całkiem niewielkie pieniądze kompletne usługi łącznie z
wynajmem serwerów bazodanowych i pasowanych pod klienta aplikacji ERP.
Kiedyś korzystaliśmy z usług takiej firmy i dobrze ten czas wspominam.
--
M.   /odpowiadając na priv zmień px na pl/

Dnia 2013-02-21, o godz. 09:36:57
Michal Kawecki <kkwinto@o2.px> napisał(a):

Tego jeszcze nie wiadomo, ale skoro człowiek pyta o podstawy, to
pewnie chodzi o jakieś rozwiązanie stawiane własnymi siłami, bez
pomocy firmy wyspecjalizowanej w budowaniu środowisk ERP. Ergo - dla
max 20-30 userów. W przeliczeniu na usera koszty takiej serwerowni
będą bardzo wysokie, stąd była moja sugestia rozważenia kolokacji.

Ale nie zawsze rozwiązanie za pomocą kolokacji jest to dopuszczalne. I
nie chodzi tu o cenę a np. o rodzaj przechowywanych danych. Np. część
danych w mojej firmie to dane wrażliwe i nie jest możliwa żadna
kolokacja nawet jeśli rozwiązanie z własną serwerownią jest
zdecydowanie droższe. Z serwerownią i kosztami też bywa różnie czasami
jest dostępna własna za niewielkie pieniądze.

Tu opowieść z życia wzięta. ;-) Moja żona wynajmowała przez 3 lata lokal
na restaurację. W ramach czynszu za lokal miała też niewielką
serwerownię: 2 szafy 42U, klimatyzacja, solidne zamknięcie, podwójne
zasilanie z dwóch źródeł, system ppoż, dociągnięty światłowód do
jednego z prowajderów, patchpanele nawet w szafach, okablowanie lokalu
etc.. Myk był w tym że wejście do pomieszczenia było z zaplecza
restauracji i były w nim także przyłącza energetyczne do wynajmowanego
lokalu. Właściciel budynku potraktował to jako powierzchnię wspólną
płaciliśmy 6PLN+VAT za metr pomieszczenia. Po prostu kilka lat temu
zaprojektowano to pod inne cele a że nikt nie chciał wynająć to tak to
zostało. Przez 3 lata miałem swoja małą prywatna serwerownię. Nawte
kolokowałem serwery kumpli. Niestety - gastronomia leci od roku w dół i
z lokalu zrezygnowaliśmy. I nie mam już swojej serwerowni. ;-)

Czasami jest lepiej niż się wydaje na pierwszy rzut oka bo np.
serwerownia już jest tylko trzeba ja doposażyć w jakiś sprzęt.

Zdrówko

W dniu 2013-02-20 22:57, Andrzej Lawa pisze:

Tak z ciekawostek: profesjonalny serwer z wypasionymi dyskami SAS 15krpm
- ciągły transfer z dysku do /dev/null to jakieś 130MB/s. Ten sam test
na "domowym" pececie (płyta sabertooth) z "zielonymi" dyskami WD (SATA)
chodzącymi w mirrorze - ponad 90MB/s (i to mimo tego, że na tej samej
programowej macierzy chodzi kilka serwerów, włącznie z dyskiem
sieciowym, oraz kilka wirtualnych urządzeń sieciowych, a ten SASowy jest
golutki)

Tak, wiem, przy zapisie będzie dużo gorzej i nie mierzę czasu dostępu do
danych tylko ciągły transfer (około gigabajta).

Ale to tylko taka ciekawostka :)

Nie piszesz, jaki sterownik macierzowy jest w serwerze, a to jest bardzo istotny element. Taki "RAID"  na pececie ma się nijak do porządnego sterownika z dużą ilością cache na pokładzie, o przyszłej rozbudowie i ilości dysków jakie można podpiąć nie wspominając.

R

W dniu 21.02.2013 08:36, Robson pisze:

Nie piszesz, jaki sterownik macierzowy jest w serwerze, a to jest bardzo
istotny element. Taki "RAID"  na pececie ma się nijak do porządnego
sterownika z dużą ilością cache na pokładzie, o przyszłej rozbudowie i
ilości dysków jakie można podpiąć nie wspominając.

Zwracam uwagę, że taki sterownik macierzowy to z reguły także pecet ze
specjalizowanym linuxem w bajeranckiej obudowie i z kosmiczną ceną ;)

--
Świadomie psujący kodowanie i formatowanie wierszy
są jak srający z lenistwa i głupoty na środku pokoju.
I jeszcze ci durnie tłumaczą to nowoczesnością...

W dniu 2013-02-21 08:47, Andrzej Lawa pisze:

W dniu 21.02.2013 08:36, Robson pisze:

Nie piszesz, jaki sterownik macierzowy jest w serwerze, a to jest bardzo
istotny element. Taki "RAID"  na pececie ma się nijak do porządnego
sterownika z dużą ilością cache na pokładzie, o przyszłej rozbudowie i
ilości dysków jakie można podpiąć nie wspominając.

Zwracam uwagę, że taki sterownik macierzowy to z reguły także pecet ze
specjalizowanym linuxem w bajeranckiej obudowie i z kosmiczną ceną ;)

Hmm, raczej karta, bez obudowy. To miałem na myśli.

R