DRBD Proxy / WAN

Chciałbym rozważyć użycie DRBD do replikacji danych między lokalizacją podstawową a pomocniczą. Początkowy plan zakłada utworzenie tunelu VPN między nimi; pierwotny koniec za pomocą wycinka podwójnego łącza T1 i ustawienie lokalizacji wtórnej na linii kabel / dsl.

Drugorzędne będą istnieć tylko dla DR - „nigdy” nie powielą się z powrotem na podstawowym.

Czy ktoś zrobił / zmęczył / używa czegoś takiego i jakie są twoje doświadczenia z tym.

Linbit ma również (płatny) produkt proxy DRBD, który powinien być zaprojektowany do pracy w łączach typu WAN (kompresja, wiele peerów). Ktoś tego próbował?

Nie mogę mówić za DRBD Proxy, ale zwykły DRBD nie spodoba się tak bardzo.

Przy nawet ograniczonej aktywności można łatwo nasycić podwójny T1 (2x 1,5 Mb / s; w przypadku liczb okrągłych 300 KB / s). 300KB / s może zostać pobrane przez samo logowanie aplikacji, nie mówiąc już o robieniu czegoś interesującego na serwerze. Wyklucza to synchroniczną replikację ( protokół C ), nie mówiąc już o dodaniu do równania opóźnienia w sieci VPN.

Replikacja asynchroniczna ( protokół A ) może technicznie działać, ale spodziewałbym się, że ta wtórna będzie tak nieaktualna, że ​​nie będzie użyteczna w przypadku awarii (replika może być opóźniona o kilka godzin w ciągu dnia)

Synchroniczna pamięć ( protokół B ) nie pomoże, ponieważ nadal jest ograniczona przez problem z przepustowością.

Oczekuję, że serwer proxy DRBD nadal będzie cierpiał z powodu podobnych problemów, powodując głównie opóźnienie replikacji z powodu ograniczonej przepustowości.

Zalecam, abyś ponownie ocenił swoją strategię DR, aby ustalić, przeciwko czemu łagodzisz; awaria sprzętu lub awaria witryny.

W przypadku ochrony przed awarią witryny można uzyskać lepszy przebieg dzięki transferom o niższej przepustowości / wyższej gęstości w przypadku jednej (lub obu) lokalizacji o ograniczonej przepustowości. Niektórymi przykładami tej techniki są rsync (transfery over-the-wire ograniczają się do zmian w plikach między uruchomieniami - zamiast dla każdej zmiany dla każdej zmiany - plus pewne obciążenie protokołu; można uruchomić przez SSH, aby dalej szyfrować i kompresować ruch) i wysyłka dziennika bazy danych (przesyłanie skompresowanych dzienników bazy danych do odtworzenia na skrzynce DR może zużywać mniej przepustowości niż przesyłanie pełnego zrzutu bazy danych).

Jeśli zabezpieczysz się przed awarią sprzętu, lokalna replika DRBD połączona z zwrotnicą GigE będzie działała dobrze, pozwoli na w pełni synchroniczne aktualizacje i umożliwi weryfikację online, aby udowodnić, że dane są spójne w obu węzłach. Nadal możesz połączyć tę opcję z ograniczoną replikacją plików do witryny DR, aby zabezpieczyć się przed awarią witryny podstawowej.

DRBD-Proxy będzie działał dobrze, pod warunkiem, że nie nasycasz linków T1 przez cały czas. Wysyłamy wiele plików 2 TB przez połączenie DRBD-Proxy (przyznane z łączem 100 megabit) bez żadnych problemów. Pod warunkiem, że masz wystarczającą ilość pamięci RAM dla serwera proxy, a liczba zapisów nie jest tak wysoka, że ​​T1 nie może sobie z tym poradzić. Chciałbyś jednak użyć trybu asynchronicznego do replikacji.