IT602 Internet File Handouts

Information Technology Infrastructure

Various Kinds of Architecture

•  Business architecture
•  Enterprise architecture
•  Data architecture,
•  Application architecture and
•  Infrastructure architecture

Is there a General Definition of IT Infrastructure?

No generally accepted definition of IT infrastructure seems to exist In literature, many definitions of IT infrastructure are described. Some of them are:

IT Infrastructure

IT infrastructure consists of the equipment, systems, software, and services used in common across an organization, regardless of mission/program/project. IT Infrastructure also serves as the foundation upon which mission/program/projectspecific systems and capabilities are built. What infrastructure comprises dependents on: Who you ask What their point of view is

For most people, infrastructure is invisible and taken for granted

Introduction to Non-Functional Attributes

IT infrastructure provides services to applications Many of these services can be defined as functions such as Disk space, Processing, Connectivity However most of these services are non-functional in nature

Non-Functional Attributes

Non-functional attributes describe the qualitative behavior of the system rather than its specific functionality and these include Security Performnace Recoverability Testtability Scalability

Handling Conflicting NFRs

It is unusual to encounter conflicting NFRs for instance users may want a system that is secure but not want to be bothered by passwords It is the task of the infrastructure architect to balance these NFRs, in some cases some NFRs may take priority over others and the architect must involve the relevant stakeholders

Everyone expects their infrastructure to be available all the time A 100% guaranteed availability of an infrastructure is impossible

A fact of

life

There is always a chance of downtime.

Calculationon of Aavailability

 Availability can neither be calculated, nor guaranteed upfront It can only be reported on afterwards, when a system has run for some years  Over the years, much knowledge and experience is gained on how to design high available systems Failover

Structured programming Avoiding Single Points of Failures (SPOFs) Implementing systems management  The availability of a system is usually expressed as a percentage of uptime in a given time period, usually one year or one month  Example for downtime expressed as a percentage per year

Downtime · per year · Downtime · per month · Downtime per week

99.8% 17.5 hours 86.2 minutes 20.2 minutes 99.9% ("three nines") 8.8 hours 43.2 minutes 10.1 minutes 99.99% ("four nines") 52.6 minutes 4.3 minutes 1.0 minutes 99.999% ("five nines") 5.3 minutes 25.9 seconds 6.1 seconds Typical requirements used in service level agreements today are 99.8% or 99.9% availability per month for a full IT system  The availability of the infrastructure must be much higher Typically in the range of 99.99% or higher  99.999% uptime is also known as carrier grade availability For one component, higher availability levels for a complete system are very uncommon, as they are almost impossible to reach  It is a good practice to agree on the maximum frequency of unavailability

MTBF and MTTR

 Mean Time Between Failures (MTBF)

•  The average time that passes between failures

 Mean Time To Repair (MTTR)

•  The time it takes to recover from a failure

Some components have higher MTBF than others Some typical MTB’s:

Component

MTBF (hours)

Hard disk 750,000 Power supply 100,000 Fan 100,000 Ethernet Network Switch 350,000 RAM 1,000,000

MTTR

 MTTR can be kept low by:

•  Having a service contract with the supplier
•  Having spare parts on-site
•  Automated redundancy and failover

 Steps to complete repairs:

•  Notification of the fault (time before seeing an alarm message)
•  Processing the alarm
•  Finding the root cause of the error
•  Looking up repair information
•  Getting spare components from storage  Having technician come to the datacenter with the spare component  Physically repairing the fault  Restarting and testing the component

 Calculation Examples

Serial components: One defect leads to downtime

Example: the above system’s availability is: 0.9999200 × 0.9999200× 0.9999733 × 0 . 9999920 × 0.9999840 × 0.9999680=0.9997 (each components’ availability is at least 99.99%) Parallel components: One defect: no downtime!

But beware of SPOFs!

Calculate availability:

A =1−¿

Total availability ¿ 1−¿ = 99.99%

Sources of Unavailability - Human Errors

80% of outages impacting mission-critical services is caused by people and process issues

Examples:

 Performing a test in the production environment  Switching off the wrong component for repair  Swapping a good working disk in a RAID set instead of the defective one

Component · MTBF (h) · MTTR (h) · in %

Power supply 100,000 0.9999200 99.99200 Fan 100,000 0.9999200 99.99200 System board 300,000 0.9999733 99.99733 Memory 1,000,000 0,9999920 99.99920 CPU 500,000 0.9999840 99.99840 Network Interface Controller (NIC) 250,000 0.9999680 99.99680

•  Restoring the wrong backup tape to production
•  Accidentally removing files Mail folders, configuration files
•  Accidentally removing database entries Drop table x instead of drop table y

Sources of Uavailability - Software Bugs

Because of the complexity of the software, it is nearly impossible (and very costly) to create bug-free software Application software bugs can stop an entire system Operating systems are software too Operating systems containing bugs can lead to

•  corrupted file systems,
•  network failures, or
•  other sources of unavailability

Sources of Unavailability - Planned Maintenance

 Sometimes needed to perform systems management tasks:

•  Upgrading hardware or software
•  Implementing software changes
•  Migrating data
•  Creation of backups

 During planned maintenance the system is more vulnerable to downtime than under normal circumstances

•  A temporary SPOF could be introduced
•  Systems managers could make mistakes

Sources of Unavailability - Physical Defects

 Everything breaks down eventually  Mechanical parts are most likely to break first  Examples:

•  Fans for cooling equipment usually break because of dust in the bearings
•  Disk drives contain moving parts
•  Tapes are very vulnerable to defects as the tape is spun on and off the reels all the time
•  Tape drives contain very sensitive pieces of mechanics that can break easily

 Sources of Unavailability - Bathtub Curve

 A component failure is most likely when the component is new  Sometimes a component doesn't even work at all when unpacked for the first time. This is called a DOA component–Dead On Arrival.  When a component still works after the first month, it is likely that it will continue working without failure until the end of its life

Sources of Unavailability - Environmental Issues

 Environmental issues can cause downtime. Issues with Power Cooling External factors like: Disasters Fire Earthquakes Flooding

Sources of Uavailability - Complexity of the Infrastructure

 Adding more components to an overall system design can undermine high

 Even if the extra components are implemented to achieve high availability  Complex systems  Have more potential points of failure  Are more difficult to implement correctly  Are harder to manage  Sometimes it is better to just have an extra spare system in the closet than to use complex redundant systems

Availability Patterns

 A single point of failure (SPOF) is a component in the infrastructure that, if it fails, causes downtime to the entire system.  SPOFs should be avoided in IT infrastructures as they pose a large risk to the availability of a system.  We just need to know what is shared and if the risk of sharing is acceptable.  To eliminate SPOFs, a combination of redundancy, failover, and fallback can be used.

 Redundancy is the duplication of critical components in a single system, to avoid a single point of failure (SPOF)