{"id":4027,"date":"2018-10-19T16:30:13","date_gmt":"2018-10-19T16:30:13","guid":{"rendered":"https:\/\/dbtut.com\/?p=4027"},"modified":"2018-12-06T08:40:18","modified_gmt":"2018-12-06T08:40:18","slug":"high-availability-part-i","status":"publish","type":"post","link":"https:\/\/dbtut.com\/index.php\/2018\/10\/19\/high-availability-part-i\/","title":{"rendered":"High Availability Part I"},"content":{"rendered":"
<\/p>\n
Unplanned outages are very expensive, and the cost of downtime is rising as almost all mission critical systems are fully automated. Industries like banking and finance, telecommunication systems, Transportation systems, airline reservation systems etc. have fully automated their end-to-end processes. The stakes are high in building robust applications to run these industries.<\/p>\n
To ensure high availability of these systems, these applications should be design and implemented with high availability needs from the start.<\/p>\n
If you are building a new application, you need to take into account the proper high availability solution by integrating various high availability considerations into your current development methodology.<\/p>\n
The first part of this article defines many high availability terms.<\/p>\n
Today you can take advantage of on-premises options, cloud options, and various hybrid options.<\/p>\n
Many other combinations of cloud and hosted options are being used these days. This includes using Infrastructure as a service (IaaS), fully hosted infrastructure (hardware you rent), and colocation (rented servers in someone else\u2019s racks). These solutions are still not fool proof as component within these stack may fail and renders the application unavailable.<\/p>\n
Example, an application will be available in the cloud but if the application cannot be accessed by a user via the network, it is essentially \u201cdown.\u201d<\/p>\n
With a move toward more cloud based or hybrid application solutions, the emphasis of your high availability focus may also be refocused. And, to top things off, there is a human error aspect running through all these components as well. If you reduce or eliminate human errors (bringing a database (DB) offline accidentally, deleting a table\u2019s data in error, and so on), you increase your system\u2019s availability greatly. Continuous application availability (or high availability) involves three major variables:<\/p>\n
Uptime<\/strong>\u2014the time during which your application is up, running, and available to the end users.<\/p>\n
Planned downtime<\/strong>\u2014the time during which IT makes one or more of the system stacks unavailable for planned maintenance, upgrades, etc.<\/p>\n
Unplanned downtime<\/strong>\u2014the time during which the system is unavailable due to failure\u2014human error, hardware failure, software failure, or natural disaster (earthquake, tornado, and so on).<\/p>\n
As you may already know from your own personal experience, the planned downtime contributes the biggest share of unavailability on most systems. It involves things such as hardware upgrades; OS upgrades and application of service packs to the DB, OS, or applications. However, there is a steady trend to adopt hardware and software platforms that allow for this element to be minimized (and, often, completely eliminated). For instance, many vendors offer systems whose hardware components, such as CPUs, disk drives, and even memory, are \u201chot swappable.\u201d (Engineered systems, a typical example is Oracle Exadata Machine and Oracle Database Appliance) But the price of these systems tends to be high.<\/p>\n
Any downtime, planned or unplanned, is factored into your overall requirements of what you need for a high availability system. You can \u201cdesign in\u201d uptime to your overall system stack and application architectures by using basic distributed data techniques, basic backup and recovery practices, and basic application clustering techniques, as well as by leveraging hardware solutions that are almost completely resilient to failures.<\/p>\n
Unplanned downtime usually takes the form of memory failures, disk drive failures, database corruptions (both logical and physical), data integrity breakdowns, virus breakouts, application errors, OS failures, network failures, natural disasters, and plain and simple human errors. There are basically two types of unplanned downtime:<\/p>\n
Downtime that is \u201crecoverable\u201d by normal recovery mechanisms<\/strong>\u2014this includes downtime caused by things like swapping in a new hard drive to replace a failed one and then bringing the system back up.<\/p>\n
Downtime that is \u201cnot recoverable\u201d and that makes your system completely unavailable and unable to be recovered locally<\/strong>\u2014this includes things such as a natural disaster or any other unplanned downtime that affects hardware.<\/p>\n
In addition, a good disaster recovery plan is paramount to any company\u2019s critical application implementation and should be part of your high availability planning.<\/p>\n
If you simply apply a standard high availability technique to all your applications, you will probably sacrifice something that may turn out to be equally important (such as performance or recovery time). So, be very cautious with a blanket approach to high availability.<\/p>\n