Abillance is based on the Allycon Cloud platform operated by Stringdata. The cloud runs on highly secured servers hosted by renowned providers in London and Prague. Minimalisation of fake user identities and the 1024 bit SSL encryption are considered standard.
Data is backed up in real time via mirroring between servers and furthermore between server locations. Customer data is backed up all at once, Abillance.com does not enable individual data recovery unless specifically requested on email@example.com - due to the share-all nature of the system, it is impossible today to allow individual users to recover their data (undo changes) since such action can have disastrous impacts on our hierarchic and transitive rights management.
Providing maximum availability
Although maximum reliability of their products is claimed and provided by HW and SW manufacturers, a system failure may occur as well as fault caused by human factor. The purpose of High Availability and Disaster Recovery is to provide system availability and data consistence at all times.
The error may occur on various levels (application, operating system, server, part of a server, net elements). The main defining factor of each error is how much it affects the user data or system availability.
High Availability solutions deal with availability – just when, to provide maximum availability, is necessary to duplicate (redundancy) all elements to prevent inaccessibility as one system crashes.
Disaster Recovery deals with data security and restoration issues – data represent the most valuable part, therefore it is vital to look after them and store them. Apart from the backup process, data carrier stability etc. the time of data restoring is also very important. Restoring of large numbers of data could take a significant amount of time and during this period the user won’t be available to use the system. Therefore it is recommended to contemplate the possibility of synchronized data replication with another storage space for REL environment.
In general, the downtimes could be divided on planned or incidental. The planned ones are such downtimes that we cause on purpose. Planned downtimes are dealt with in the migration process (from test to fulltime) or by update (error corrections, new functionalities) and therefore will not be mentioned in this document any further.
Data Guard (DG) provides high accessibility, data restoring and security level when downtimes may occur. The main idea is that the operating (processing, primary) database has its own exact copy (backup, standby database), where all changes on the operating database are also applied. Both databases do match exactly and in case of downtime of the primary database all performance is done by the backup database. Speaking of database, we mean Oracle database instance (or RAC database).
The databases might be (we recommend to) localized at various locations (or providers), but only under condition of high mutual connectivity.
The innovations in new Oracle database version allow transferring of report generating (configuration generating), operating database backup, testing and implementation of operating database upgrades (so the performance of the operating database gets better) right onto the backup database. Another benefit is the possibility to upgrade to the next version right during the operations and also the option to switch automatically to backup database in the maximum performance mode.
Real application clusters
The RAC is based upon the cluster. The cluster provides, using several servers with similar content, consecutive application availability – the failover (server downtime). So, when one server shuts down, the application continues to run on different server cluster.
The cluster also improves the application performance – the scalable or load balancing. The requests run in parallel on all servers in the cluster and therefore the load is dispersed between individual servers. Thanks to this, the performance scalability is possible.
To apply this solution, it is necessary to provide information sharing on all RAC servers, i.e. using of shared storage, like the SCSI (Small Computer System Interface), NAS (Attached Storage Network) or SAN (Storage Area Network).
The Flashback Query provides an access to data history and its quick restoration. Data history is available according to the selected interval of Flashback execution. In brief, Flashback operates on Snapshot principle of changing logs.