Private Cloud o wysokiej niezawodności

Odpowiedz Nowy wątek
2018-11-05 15:32
0

Taka sytuacja.

Mała / średnia firma, 200m rozciągłość zabudowań, 20h / dobę pracuje tzw informatyka, choć w wielu porach doby są to ilościowo obszerne, ale proste operacje (inserty / bardzo proste update). Poprawnie wykonana elektryka, nie generuje sama w sobie dodatkowych problemów, ale fakt, urządzenia przemysłowe małe nie są.
Operacje "ambitne" można ograniczyć do zmiany dziennej (8-16).

Jak by nie angażując milionów złotych (ale tysiące to tak) podnieść niezawodność. Np serwer z dwoma/więcej kartami wychodzi na dwie fizycznie oddzielne podsieci. Zawieszenie / spalenie jednego switcha pozwala na pracę przynajmniej drugiej odnogi.

Modyfikując te "masowe" apliakcje całodobowe można by w razie niedostępności serwera SQL napełniać jakieś kolejki. Tylko jak zapewnić aby w razie awarii głównego serwera został odkryty broker kolejek (jeden z dwóch - w szafach w odległych skrzydłach). Żeby wytrzymać kilkanaście godzin do jakiejś kompetentnej reakcji.

AHA. Dlaczego nie public cloud? Dlatego że żaden z operatorów nie jest w stanie zapewnić w tej dzielnicy wysokowydajne i pewnej infrastruktury. Miedzianego operatora stać nawet na spalenie ich urządzenia ze dwa razy w roku, ale nic nie zrobić. Całe szczęście router providera jest przestawiony w modem, a router (z DHCP) mamy swój, wielokrotnie zostało pokazane, że fajnie działamy przy 24h braku internetu.

Mają sens takie rozważania?

Pozostało 580 znaków

2018-11-05 16:35
1

Zamiast robić dwie osobne sieci, raczej zrób to w topologii pierścienia - jeśli z jednej strony się przerwie kabel/padnie switch, całość "będzie zasilana" z drugiej. Oczywiście musisz mieć sprzęt, który będzie w stanie ogarnąć backupowy link, bo w sytuacji zrobienia pętelki na "zwykłych" switchach mogą się dziać dziwne rzeczy ;)

Ewentualnie możesz pomyśleć o zapasowym Wi-Fi, które byś odpalał w sytuacji uszkodzenia okablowania/sprzętu. Obecnie linki (chociażby Ubiquitii - sam mam kilka podpiętych i mogę polecić) na 5GHz chodzą mega stabilnie, a przy Twoich odległościach spokojnie z 200Mbit wyciągniesz (oczywiście są też rozwiązania szybsze, ale chyba nie ma takiej potrzeby).

Odnośnie padów serwera - moim zdaniem, zamiast gromadzenia zapytań SQL w jakimś tymczasowym magazynie i późniejszego ich zrzucania na zreanimowany serwer, zainteresuj się wirtualizacją. Nawet można to w miarę prosto zrobić na darmowym VMware (wymaga to trochę ręcznego przełączania w razie padu), a opcja płatna umożliwia całkowicie zautomatyzowane odpalenia serwera zapasowego w razie padu maszyny głównej w ciągu dosłownie kilkunastu sekund. Nie wiem jakiego typu dane tworzysz/obrabiasz, ani czy aplikacja korzystająca z SQL to Twoje dzieło lub gotowe rozwiązanie, ale w gromadzeniu zapytań "na zapas" widzę wiele potencjalnych problemów, zwłaszcza w sytuacji update'ów czy skasowań danych zleconych jednocześnie przez dwie maszyny, zmagazynowane w buforze, a potem zrzucone do serwera SQL.

Pytanie - czy te wszystkie zabezpieczenia robisz na zapas, czy miałeś już jakieś nieprzyjemne doświadczenia? Jeśli miałeś - napisz co się działo i w jaki sposób ratowałeś sytuację.

Wyjaśnij, co oznacza fragment "elektryka nie generuje sama w sobie dodatkowych problemów, ale fakt, urządzenia przemysłowe małe nie są". Czy chodzi o skoki napięcia wynikające z działania "dużych" urządzeń, czy może często wyskakują bezpieczniki? Tak czy siak - można dodać do każdego urządzenia w sieci UPS'a. Taki "standardowy" UPS z jednym akumulatorkiem zapewni działanie switcha przez przynajmniej kilkanaście/kilkadziesiąt minut, a co ważniejsze - ochroni go przed skokami napięcia (bo podejrzewam/wnioskuję z Twojego posta, że to jest główny problem).

A co do serwerów i ich zasilania - za kilka dni, gdy doprowadzę temat do końca, to wrzucę tutaj na bloga zdjęcia oraz opis rewolucji w zasilaniu awaryjnym serwerowni. Budżet ok. 10kpln, 8 akumulatorów 12V 200Ah każdy, przetwornica 4kW, selektor faz i parę innych fajnych spraw :)


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say
edytowany 1x, ostatnio: cerrato, 2018-11-05 16:43

Pozostało 580 znaków

2018-11-05 22:47
0

wg mnie i moich doświadczeń z podobnymi firmami (w poprzedniej pracy właśnie takie zakłady produkcyjne obsługiwaliśmy - 100-500 osób załogi, praca 3 zmiany) to prościej mieć na te 8h kumatego elektryka, który potrafi zlokalizować padniętego switcha i go wymienić. Przez ponad 10 lat pracy nie zdarzyło mi się aby gdzieś padł serwer (poza jedną sytuacją gdzie wywaliły się 3 z 4 dysków w RAIDzie i nikt tego nie zauważył ...). BTW ile tych switchy masz/planujesz bo zamiast 10-20 co 10 metrów powinieneś mieć jednego porządnego w szafie serwerowej i porozciągane kable do końcówek. Jeśli musi ich być więcej to też 2 - 3 góra, połączone między sobą i tyle. Wszystkie za UPSami.

EDIT: Modyfikacja aplikacji, które nie są przystosowane do pracy offline aby tak pracowały przy braku serwera SQLowego to wg mnie koszt przekraczający albo podobny do zakupu ww oprogramowania więc jak dla mnie to próba realizacji tego jest to, o ile soft masz kupiony, musztarda po obiedzie.


Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.
edytowany 1x, ostatnio: abrakadaber, 2018-11-05 22:50

Pozostało 580 znaków

2019-01-11 22:35
0

nadal poszukujesz Private Cloud?
Przy większych zasobach lepszym rozwiązaniem jest Private Cloud - raz ze względów na koszty a dwa otrzymujesz większe możliwości konfiguracyjne.

Pozostało 580 znaków

2019-01-12 13:24
Nadziany Orzeł
0

Cloud i wysoka niezawodność to antonimy. Piszę z doświadczenia jako admin.

Pozostało 580 znaków

2019-01-14 11:24
1
Nadziany Orzeł napisał(a):

Cloud i wysoka niezawodność to antonimy. Piszę z doświadczenia jako admin.

:) być może wszystko zależy gdzie ten Twój Private stał :) Ja mam osobiście inne doświadczenia. Pracowałem na dedyku i privacie. Przy dedykach uszkodzenie pamięci spowodowało bardzo duży problem... z brakiem dostępu do usług i czasem ich rozwiązania.

W prawidłowym privacie zasoby są redundantne i tego typu problem nie powinien wystąpić.

Pozdrawiam

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0