Kort fortalt er Vortex satt opp slik (diagrammet under svarer til en virtuell host, f.eks. www.usit.uio.no):
-------- --------------- -----------
| | | | | |
| Apache | --- | Resin/Vortex | --- | Oracle |
| | | | Primær | | | |
-------- | --------------- | -----------
| |
| | -----------
| | | |
| - | Filsystem |
| | |
| -----------
|
|
| --------------- -----------
| | | | |
- | Resin/Vortex | --- | Oracle |
| Failover | | | |
--------------- | -----------
|
| -----------
| | |
- | Filsystem |
| |
-----------
Dette fungerer slik at når Resin svarer på primærløsningen, vil alle requester gå til denne instansen (dette styres i Apache/mod_caucho). Dersom primærinstansen er nede, vil Apache rute alle requester til failover-instansen. Dette gir oss noe redundans med hensyn til stabilitet, og benyttes også når Vortex skal oppgraderes: først taes primærinstansen ned for oppgradering, og mens dette pågår svarer failoverinstansen på requestene.
Primær- og failoverinstansene kjører mot forskjellige databaser, og har hver sin kopi av fildataene. Dette betyr at for hver kontrollerte nedtagning av primærløsningene må data synkroniseres til sekundærløsningen. Dette gjøres med eksport/import av databasen, og rsync av fildataene. Dette gjøres bl.a. fra cron hver natt, for å holde failoverløsningen mest mulig oppdatert i tilfelle primærløsningen skulle gå ned. Failoverløsningene er satt opp som read-only, ettersom vi kun støtter synkronisering av data én vei (fra primær til failover).