Зарових се в темата за едни много специализирани решения с Oracle RAC: Extended Clusters. Това е система при която имаме голямо разстояние (километри) между нодовете в един клъстер.
Предизвикателствата за изграждане на такова решение са няколко. Първо, трябва да се осигури mirroring на сориджите. За да бъде използвано за DR, трябва да има сторидж на двете места. Двата сториджа трябва да са абсолютно синхронизирани: или с възможностите на самия сторидж (array-based mirroring), или чрез LVM (примерно Oracle ASM). И двата варианта имат плюсове и минуси. Най-интересното в случая е, че това синхронизиране трябва да става в рамките на милисекунди. При разстояния от много километри това се постига само чрез специализирани оптични трасета. И понеже информацията, която се предава, е ужасно много (всичките I/O операции на една БД!), използват се DWDM (Dark Fiber) трасета.
Всичко е доста комплексно: освен SAN трасето (което допуска латентност до десетина милисекунди, която е теоретични изпълнима с Dark Fiber до ~100 KM), имаме и interconnect, който трудно понася латентност по-голяма от 5-8 микросекунди (за Enterprise решения). Interconnect трафика трябва да върви по отделно трасе, а към това се добавя и public network свързаността (е там са допустими десетки до стотина микросекунди латентност). Тези три трафика освен че трябва да са независими (не бива да минават по общо влакно), трябва и да бъдат redundant. Това удоволствие лесно достига до стотици хиляди долари само за мрежовата свързаност.
Следващото предизвикателство е конфигурирането на voting disk. Докато при един общ сторидж няма както толкова да се обърка, при отдалечени сториджи ако се направи по най-елементарния начин ще се получи предпоставка за split-brain. Трябва да се направи един (по-добре два) voting disk на всеки сторидж и поне още един на трети, независим и отдалечен от другите два сайта. Това е възможно с Oracle 10g R2 – дори третия сайт може да бъде един достатъчно отговорен сървър с nfs. Но все пак си има нужда от трети сайт.
А каква е ползата? Много спорна, особено за наистина много километри отстояние. До преди 10g R2 има смисъл то такова решение защото времето за failover при отпадане на един сайт е в рамките на секудни и не се изизква човешка намеса. В Oracle 10g R2 Data Guard има т. нар. Fast-Start Failover, който успява да постигне същото (но пак се изисква трети сайт). Другo предимство на Extended Cluster (срещу Data Guard) е, че всичките машини се използват активно и реално. Но цената на една DG standby система е сравнително малка в сравнение с цената и комплексността на мрежовата среда за Extended Cluster.
Истината е, че такива решения има реално имплементирани (и то десетки). Най-отдалеченото е в една европейска телекомуникационна компания, която има 2 сайта на 48 км разстояние. А в Oracle 11g се подготвят специални оптимизации (примерно в ASM) за Extended RAC.
