Private Cloud o wysokiej niezawodności

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?

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 :)

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.

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