Tomasz
Serwański
Microsoft Dynamics
CRM - konsultant
biznesowy
Adam
B.
Oracle Certified
Master
konto usunięte
konto usunięte
Jakub Chojnacki:
napisać coś od strony praktycznej z własnego doświadczenia to chętnie poczytam.
Adam
B.
Oracle Certified
Master
Jakub Chojnacki:
Ciekawy temat. Przyznam szczerze że pierwszy raz się spotykam z takim zastosowania RAC.
Ciekaw jestem czy ktoś w Polsce utrzymuje produkcyjnie takie rozwiązanie i jakie są główne problemy. Jak ktoś może napisać coś od strony praktycznej z własnego doświadczenia to chętnie poczytam.
Tomasz
Serwański
Microsoft Dynamics
CRM - konsultant
biznesowy
Adam Boliński:a, to ja jestem ciekwaw czy to isstniejace rozwiazanie:
Powiedzmy , że jest ale odległość to około 23 km , pracuje bez problemu , baza OLTP.
Jeżeli chodzi o problemy to rzeczywiście problem są opóźnienia na Interconnect.
To tak ogólnie i bardzo bardzo zwięźle mówiąc, teraz jestem na etapie projektowania/konfiguracji
RAC Extended w odległości 35km.
Opowiem o wynikach/spostrzeżeniach i problemach jeśli ktoś będzie zainteresowany.
Adam
B.
Oracle Certified
Master
Krzysztof P.:
Jakub Chojnacki:
napisać coś od strony praktycznej z własnego doświadczenia to chętnie poczytam.
Praktycznie to nic z tego nie wyszło, ale trochę na ten temat poczytałem.
1. Przepustowość łącza musi zapewnić jakieś minimum, które wystarczy na obsłużenie kolejki I/O. Po prostu w trakcie zapisu nie może się pojawić sytuacja, w której ilość danych czekających w kolejce do zapisu będzie stale rosnąć do momentu, w którym przepełni się bufor. Trzeba więc oszacować przepustowość łącza.
2. W konfiguracji voting disków musi być obecne trzecie urządzenie, które zapewni prawidłowe zachowanie klastra podczas głosowania w przypadku awarii. Tj. nie powinno być sytuacji, w której voting disks są przeważające w jednym lub drugim ośrodku.
3. Z w/w wymagań wyszło, że najprościej jest zrobić RAC w jednym ośrodku i bazę standby (single) w drugim :)
Adam
B.
Oracle Certified
Master
Tomasz Serwański:
Adam Boliński:a, to ja jestem ciekwaw czy to isstniejace rozwiazanie:
Powiedzmy , że jest ale odległość to około 23 km , pracuje bez problemu , baza OLTP.
Jeżeli chodzi o problemy to rzeczywiście problem są opóźnienia na Interconnect.
To tak ogólnie i bardzo bardzo zwięźle mówiąc, teraz jestem na etapie projektowania/konfiguracji
RAC Extended w odległości 35km.
Opowiem o wynikach/spostrzeżeniach i problemach jeśli ktoś będzie zainteresowany.
- mialo jakies awarie / rozpiecia polacze
- czy w takim wypadku oba osrodki dzialaly rownolegle
- co sie dzialo z danymi po ponownym spieciu polaczenia (synchronizacja? czy sie rozpadly?)
Tomasz
Serwański
Microsoft Dynamics
CRM - konsultant
biznesowy
Adam Boliński:a to czekaj.. klientowi ktos nadagal ze rac extended w razie awarii zapewni dzialanie rownolegle obu (rodzielonych) osrodkow i pozniejsza synchronizacje danych; malo mi sie to prawdopodobne wydawalo :) no ale skoro klient mowi.. natomiast jak rozumiem w razie awarii aktywny jest tylko master, i wszelkie proby gadania przez klientow do slave'a nie zadzialaja, tak?
- Rozpięcie było , oczywiście między lokalizacją 1 a 2 , o tym kto jest Master decyduje lokalizacja 3 mówiąc skrótowo.
- Nie działały równolegle o to można być spokojnym
- Dane się dosynchronizowały z Mastera (tylko zmienione bloki)
Tomasz
Serwański
Microsoft Dynamics
CRM - konsultant
biznesowy
Tomasz Wiśniewski:jasne; czyli active/active jest tylko dla sytuacji kiedy dziala ic i siec ip miedzy lokalizacjami, a kazdy przypadek awarii (uszkodzenie ip lub ic) powoduje awarie czyli ustalenie jednego osrodka jako active a drugi jest out, a?
Teoretycznie mogą działać 2 DC ale praktycznie opóźnienia będą takie że w takim wypadku wszystko umrze na ic. Nie wiem co miał ktoś na myśli mówiąc o "późniejszej synchronizacji danych". RAC korzysta z tych samych dysków, wymienia zmienione bloki pomiędzy SGA więc o "późniejszej synchronizacji" w specyfikacji RAC nie ma mowy. To jest moim zdaniem opis DG ew ADG.
konto usunięte
Tomasz Wiśniewski:
Możliwe jest jeszcze wykorzystanie golden gate to synchronizacji ale to inna baja, fajnie wygląda na w broszurce a naprawdę cudów nie ma. Słyszałem że Krzysztof Pułapa stawiał coś takiego i nie był zadowolony ;)
Adam
B.
Oracle Certified
Master
Tomasz Wiśniewski:
Teoretycznie mogą działać 2 DC ale praktycznie opóźnienia będą takie że w takim wypadku wszystko umrze na ic. Nie wiem co miał ktoś na myśli mówiąc o "późniejszej synchronizacji danych". RAC korzysta z tych samych dysków, wymienia zmienione bloki pomiędzy SGA więc o "późniejszej synchronizacji" w specyfikacji RAC nie ma mowy. To jest moim zdaniem opis DG ew ADG.
Jarosław M. DBA
Tomasz
Serwański
Microsoft Dynamics
CRM - konsultant
biznesowy
Jarosław M.:dwie macierze w dwu lokalizacjach; i glownie o macierze sie cala filozofia rozbija, skoro nawet a-srdf zaklada opoznienie do 30-60 sekund na duzych dystansach to nie bardzo moge zaakceptowac fakt ze rac moze na takich dystansach dzialac bez wyraznych opoznien..
Jak to działa? Jeden nod w jednym site i drugi w drugim site i jeden storage zapięty do obu nodów? + interconnecty itd. itp. ale chodzi mi o storage ?
Jarosław M. DBA
konto usunięte
Jarosław M.:
Te dwie macierze muszą się mirrorować tak? Jakimś rozwiązaniem oracle czy mechanizmami zewnętrznymi? A już widzę clvm albo slvm
konto usunięte
Następna dyskusja:
пропозиції роботи
