Understanding the levels of IT service
by Andrea Vacche, Patrik Uytterhoeven, Rihards Olups
Zabbix: Enterprise Network Monitoring Made Easy
- Zabbix: Enterprise Network Monitoring Made Easy
- Table of Contents
- Zabbix: Enterprise Network Monitoring Made Easy
- Zabbix: Enterprise Network Monitoring Made Easy
- Credits
- Preface
- I. Module 1
- 1. Getting Started with Zabbix
- The first steps in monitoring
- Zabbix features and architecture
- Installation
- Summary
- 2. Getting Your First Notification
- 3. Monitoring with Zabbix Agents and Basic Protocols
- 4. Monitoring SNMP Devices
- 5. Managing Hosts, Users, and Permissions
- 6. Detecting Problems with Triggers
- 7. Acting upon Monitored Conditions
- 8. Simplifying Complex Configurations with Templates
- 9. Visualizing Data with Graphs and Maps
- 10. Visualizing Data with Screens and Slideshows
- 11. Advanced Item Monitoring
- 12. Automating Configuration
- 13. Monitoring Web Pages
- 14. Monitoring Windows
- 15. High-Level Business Service Monitoring
- 16. Monitoring IPMI Devices
- 17. Monitoring Java Applications
- 18. Monitoring VMware
- 19. Using Proxies to Monitor Remote Locations
- 20. Encrypting Zabbix Traffic
- 21. Working Closely with Data
- 22. Zabbix Maintenance
- A. Troubleshooting
- B. Being Part of the Community
- 1. Getting Started with Zabbix
- II. Module 2
- 1. Zabbix Configuration
- 2. Getting Around in Zabbix
- 3. Groups, Users, and Permissions
- 4. Monitoring with Zabbix
- Introduction
- Active agents
- Passive agents
- Extending agents
- SNMP checks
- Internal checks
- Zabbix trapper
- IPMI checks
- JMX checks
- Aggregate checks
- External checks
- Database monitoring
- Checks with SSH
- Checks with Telnet
- Calculated checks
- Building web scenarios
- Monitoring web scenarios
- Some advanced monitoring tricks
- Autoinventory
- 5. Testing with Triggers in Zabbix
- 6. Working with Templates
- 7. Data Visualization and Reporting in Zabbix
- 8. Monitoring VMware and Proxies
- 9. Autodiscovery
- 10. Zabbix Maintenance and API
- C. Upgrading and Troubleshooting Zabbix
- III. Module 3
- 1. Deploying Zabbix
- 2. Distributed Monitoring
- 3. High Availability and Failover
- Understanding high availability
- Understanding the levels of IT service
- Some considerations about high availability
- Implementing high availability on a web server
- Configuring the Zabbix server for high availability
- Implementing high availability for a database
- Summary
- 4. Collecting Data
- 5. Visualizing Data
- 6. Managing Alerts
- 7. Managing Templates
- 8. Handling External Scripts
- 9. Extending Zabbix
- 10. Integrating Zabbix
- D. Bibliography
- Index
Availability is directly tied with service level and is normally defined as a percentage. It is the percentage of uptime over a defined period. The availability that you can guarantee is your service level. The following table shows what exactly this means by considering the maximum admitted downtime for a few of the frequently used availability percentages:
|
Availability percentage |
Max downtime per year |
Max downtime per month |
Max downtime per week |
|---|---|---|---|
|
90% called one nine |
36.5 days |
72 hours |
16.8 hours |
|
95% |
18.25 days |
36 hours |
8.4 hours |
|
99% called two nines |
3.65 days |
7.20 hours |
1.68 hours |
|
99.5% |
1.83 days |
3.60 hours |
50.4 minutes |
|
99.9% called three nines |
8.76 hours |
43.8 minutes |
10.1 minutes |
|
99.95% |
4.38 hours |
21.56 minutes |
5.04 minutes |
|
99.99% called four nines |
52.56 minutes |
4.32 minutes |
1.01 minutes |
|
99.999% called five nines |
5.26 minutes |
25.9 seconds |
6.05 seconds |
|
99.9999% called six nines |
31.5 seconds |
2.59 seconds |
0.605 seconds |
|
99.99999% called seven nines |
3.15 seconds |
0.259 seconds |
0.0605 seconds |
The availability must be calculated end to end, and all the components required to run the service must be available. The next sentence may seem a paradox; the more hardware you add and the more failure points you need to consider, the greater the difficulty in implementing an efficient solution. Also, an important point to consider is how easy the patching of your HA system and its maintenance will be. A truly highly available system implies that human intervention is not needed; for example, if you need to agree to a five nines service level, the human (your system administrator) will have only one second of downtime per day, so here the system must respond to the issue automatically. Instead, if you agree to a two nines service level agreement (SLA), the downtime per day can be of 15 minutes; here, the human intervention is realistic, but unfortunately this SLA is not a common case. Now, while agreeing to an SLA, the mean time to recovery is an important factor to consider.
The first thing to do is to keep the architecture as simple as possible and reduce the number of actors in play to a minimum. The simpler the architecture, the less the effort required to maintain, administer, and monitor it. All that the HA architecture needs is to avoid a single point of failure, and it needs to be as simple as possible. For this reason, the solution presented here is easy to understand, tested in production environments, and quite easy to implement and maintain.
Unfortunately, a highly available infrastructure is not designed to achieve the highest performance possible. This is because it is normal for an overhead to be introduced to keep two servers updated, and a highly available infrastructure is not designed for maximum throughput. Also, there are implementations that consider using the standby server as a read-only server to reduce the load on a primary node, using then an unused/inactive server.
-
No Comment