| Data: 2013-02-22 07:10:48 | |
| Autor: MK | |
| Interfejs do polaczenia serwera z macierza dyskowa | |
|
Witam i dziekuje za odpowiedzi.
Jezeli chodzi o kolokacje do zewnetrznej serwerowni nie wchodzi za bardzo w gre dla typowo wewnetrznego systemu ERP (firma w jednej lokalizacji, 60 licencji na ERP). Chodzi o ochrone danych, dodatkowe umowy o ochronie, zabezpieczenie nadmiarowosci szybkich lacz, itp. W firmie jest juz serwerowania klimatyzowana z odpowiednim zabezpieczeniem przed dostepem nieupowaznionych osob wraz z szafa rackowa zakupiona na potrzeby serwerow innego dedykowanego systemu. Podsumowujac wiec ja zakupuje dwa serwery i macierz (moze byc zintegrowana z jednym z serwerow - dopuszczam takie rozwiazanie). Moje pytanie dotyczy tego czy te trzy elementy mozna sklastrowac w jeden fizycznie sprzet i na nim postawic wirtualnie serwer bazy danych (SQL), serwer na potrzeby samej aplikacji ERP i dysk macierzy na przechowywanie danych (z wysokim IOPS). Pozwoli to zachowac minimalna nadmiarowosc jezeli chodzi o awarie serwerow. Prosze mnie poprawic jezeli zle mysle. Dodatkowo w kilku specyfikacjach na sprzet serwerowy zapisane jest ze dana macierz ma miec zabezpieczenie wewnetrznego cache przed awaria tylko nie dopuszczalne jest zabezpieczenie wykorzystujace modu硑 bateryjne. Czy oznacza to, ze zabezpieczenie w oparciu o baterie jest niepewne i na wypadek awarii zasilania zbuforowane dane w cache moga bezpowrotnie byc utracone ? Jakie w takim razie sa te pamieci cache bez podtrzymania bateryjnego ? Pozdrawiam M.K. |
|
| Data: 2013-02-24 19:00:17 | |
| Autor: NiusOnly | |
| Interfejs do polaczenia serwera z macierza dyskowa | |
|
W dniu 2013-02-22 07:10, MK pisze:
Podsumowujac wiec ja zakupuje dwa serwery i macierz (moze byc zintegrowana z Zajmuje si臋 wdro偶eniami jednego z system贸w ERP i z do艣wiadczenia radzi艂bym 偶eby艣 chocia偶 zwr贸ci艂 si臋 do producenta lub firmy, kt贸ra b臋dzie to wdra偶a膰, o sizing lub najlepiej zaproponowanie konkretnej konfiguracji sprz臋towej. W moim przypadku zazwyczaj buduje si臋 klaster gdzie zar贸wno baza jak i aplikacja pracuj膮 na interfejsach wirtualnych i mog膮 dowolnie by膰 prze艂膮czane pomi臋dzy w臋z艂ami. Dodatkowo aplikacja ma specjalne modu艂y do obs艂ugi u偶ytkownik贸w i zada艅 kt贸re s膮 instalowane lokalnie i w pe艂ni wykorzystuj膮 moc 2 serwer贸w. Podczas normalnej pracy obci膮偶enie jest r贸wnowa偶one pomi臋dzy w臋z艂y klastra a podczas awarii centralny element + baza dzia艂a na sprawnym w臋藕le. Fizycznie s膮 to przynajmniej 2 serwery + oddzielna macierz po艂膮czona jednocze艣nie do wszystkich serwer贸w. Tak tak w uproszczeniu. Wracaj膮c do twojej sytuacji- je艣li chcesz to mo偶esz zbudowa膰 konfiguracje samodzielnie ale uzgodnij j膮 z kim艣 kto ju偶 mia艂 do艣wiadczenie z aplikacj膮 jak膮 wdra偶acie. Cz臋sto spotykam si臋 z sytuacj膮 偶e kto艣 ma jak膮艣 wizj臋 kt贸ra po prostu ze wzgl臋du na konkretne wymagania aplikacji (lub brak wiedzy/do艣wiadczenia klienta), nie sprawdza si臋 i ko艅czy si臋 tym 偶e trzeba wydawa膰 dodatkowe pieni膮dze na sprz臋t albo ca艂o艣膰 chodzi kulawo. Przy takiej ilo艣ci user贸w nie potrzebujesz niewiadomo jak szybkiego sprz臋tu. Skupi艂bym si臋 raczej na dobrym klastrze i wyeliminowaniu pojedynczych punkt贸w awarii tak 偶eby w razie awarii nikt nie mia艂 pretensji 偶e firma nie pracowa艂a przez 2 dni ;)
S膮 kontrolery z flashem, w razie awarii zasilania wszystko jest przepisywane do flasha. Oczywi艣cie tam te偶 jest jakie艣 podtrzymywanie zasilania ale po zapisaniu do flashu (co trwa moment) nie jest potrzebne. M. |
|