Korkean käytettävyyden tai korkean käytettävyyden ( HA ) on termi käytetään usein atk noin järjestelmäarkkitehtuuri tai palvelun ilmaisemaan, että tämä arkkitehtuurin tai palvelu on käytettävyysaste sopiva.
Saatavuus on nykyään tärkeä asia IT-infrastruktuureille. Vuoden 2007 tutkimuksessa arvioidaan, että tietotekniikkapalveluiden puuttuminen voi maksaa 440 000 euroa tunnissa, mikä on miljardeja euroja valtakunnallisesti. Tietotekniikkapalvelujen saatavuus ei ole erityisen tärkeää teollisuudessa, varsinkin jos tuotantolinja pysähtyy.
Saatavuuden parantamiseksi käytetään kahta täydentävää tapaa:
Saatavuus mitataan usein prosentteina:
| Saatavuus% | Ei käytettävissä vuodessa | Ei käytettävissä kuukaudessa | Ei käytettävissä viikossa |
|---|---|---|---|
| 90% ("uusi") | 36,5 päivää | 72 tuntia | 16,8 tuntia |
| 95% | 18,25 päivää | 36 tuntia | 8,4 tuntia |
| 98% | 7.30 päivää | 14,4 tuntia | 3,36 tuntia |
| 99% ("kaksi yhdeksää") | 3,65 päivää | 7,20 tuntia | 1,68 tuntia |
| 99,5% | 1,83 päivää | 3,60 tuntia | 50,4 minuuttia |
| 99,8% | 17.52 tuntia | 86,23 minuuttia | 20,16 minuuttia |
| 99,9% ("kolme yhdeksää") | 8,76 tuntia | 43,2 minuuttia | 10,1 minuuttia |
| 99,95% | 4,38 tuntia | 21,56 minuuttia | 5,04 minuuttia |
| 99,99% ("neljä yhdeksää") | 52,56 minuuttia | 4,32 minuuttia | 1,01 minuuttia |
| 99,999% ("viisi yhdeksää") | 5,26 minuuttia | 25,9 sekuntia | 6,05 sekuntia |
| 99,9999% ("kuusi yhdeksää") | 31,5 sekuntia | 2,59 sekuntia | 0,605 sekuntia |
Korkea käytettävyys sekoitetaan usein virheellisesti katastrofien elvytyssuunnitelmaan . Nämä ovat kaksi erilaista, toisiaan täydentävää tehtävää jatkuvan saatavuuden saavuttamiseksi .
Saatavuuden parantamiseen käytetään monia tekniikoita:
Korkea käytettävyys vaatii useimmiten sopivan huoneen: vakaa virtalähde, ilmastointi lattialla, hiukkassuodattimella, huoltopalvelu, turvapalvelu ja turvallisuus ilkeä tahallisuus ja varkaus. Huomioi myös tulipalon ja vesivahinkojen vaara. Virta- ja tiedonsiirtokaapeleiden on oltava useita ja haudattuja. Niiden ei tulisi ulottua rakennuksen maanalaiseen pysäköintialueeseen, jota nähdään liian usein Pariisin rakennuksissa. Nämä kriteerit otetaan ensimmäiseksi huomioon majoitustarjoajaa valittaessa (tapaus vuokrata korkean saatavuuden huone).
Arkkitehtuurin jokaiselle tasolle, jokaiselle komponentille, jokaiselle komponenttien väliselle linkille on määritettävä:
Sovellukselle, joka käyttää muita sovelluksia middleware synkronisessa tilassa ( verkkopalvelu on http , Tuxedo , Corba , EJB ) saatavuus nopeus hakemus liittyy vahvasti sovellusten käytettävyyttä josta se on riippuvainen. Siksi niiden sovellusten herkkyyden, joista olemme riippuvaisia, on oltava samanarvoisia tai suurempia kuin itse sovelluksen herkkyys.
Muussa tapauksessa harkitse
Tästä syystä suosimme asynkronisen väliohjelmiston käyttöä hyvän saatavuuden edistämiseksi aina kun mahdollista.
Herkkyyttä hallitaan usein redundanteilla elementeillä, joissa on kuorman tasapainotusmekanismi. (Websphere-klusteri, jossa on esimerkiksi Alteonin kuormituksen tasapainotus). Jotta tämä järjestelmä antaisi todellista hyötyä luotettavuudesta, on tarpeen varmistaa, että jos jokin elementeistä on viallinen, muilla elementeillä on riittävä teho palvelun varmistamiseksi.
Toisin sanoen kahden aktiivisen palvelimen tapauksessa, joissa on kuormituksen tasapainottaminen, yhden palvelimen tehon on kyettävä varmistamaan kuormituksen kokonaisuus. Kolmella palvelimella yhden palvelimen tehon pitäisi pystyä käsittelemään 50% kuormituksesta (olettaen, että kaatumisen todennäköisyys kahdella palvelimella samanaikaisesti on vähäinen).
Hyvän saatavuuden varmistamiseksi on tarpeetonta laittaa suuri määrä palvelimia auttamaan toisiaan. Esimerkiksi kerran käytettävissä oleva 99% käytettävissä oleva elementti antaa 99,99% käytettävyyden (todennäköisyys, että molemmat elementit epäonnistuvat samanaikaisesti = 1 / 100x1 / 100 = 1/10000).
Elementin redundanssi suoritetaan yleensä valitsemalla redundanssi useiden identtisten komponenttien kanssa. Tällöin oletetaan olevan tehokasta, että yhden komponentin vika on satunnainen ja riippumaton toisen komponentin vikaantumisesta. Tämä pätee esimerkiksi laitteistovikoihin.
Tämä ei koske kaikkia vikoja: esimerkiksi käyttöjärjestelmävika tai poikkeama ohjelmistokomponentissa voi tapahtua, kun olosuhteet ovat suotuisat, kaikille komponenteille samanaikaisesti. Tästä syystä, kun sovellus on erittäin herkkä, harkitsemme redundantteja elementtejä, joilla on eri luonteisia komponentteja, mutta jotka tarjoavat samat toiminnot. Tämä voi johtaa:
Tässä tilassa eri komponentit käsittelevät samoja tuloja ja tuottavat siten (periaatteessa) samat lähdöt.
Kaikkien komponenttien tuottamat tulokset kerätään ja sitten toteutetaan algoritmi lopullisen tuloksen tuottamiseksi. Algoritmi voi olla yksinkertainen (enemmistöäänestys) tai monimutkainen (keskiarvo, painotettu keskiarvo , mediaani jne.), Jonka tavoitteena on poistaa virheelliset tulokset, jotka johtuvat yhden komponentin toimintahäiriöstä, ja / tai tehdä komponentista luotettavampi. yhdistämällä useita hieman erilaisia tuloksia.
Tämä prosessi :
Tätä prosessia käytetään yleensä seuraavissa tapauksissa
Kun redundantti komponentti ei toimi ja sen jälkeen, kun se on korjattu, saatat haluta palauttaa sen aktiiviseen palveluun ja tarkistaa, että se todella toimii oikein, mutta tuloksia ei käytetä. Tässä tapauksessa syötteet käsitellään yhdellä (tai useammalla) luotettavaksi katsotulla komponentilla. Nämä tuottavat loppujärjestelmän hyödyntämän tuloksen. Samoja merkintöjä käsittelee myös uusi komponentti, jonka sanotaan olevan "varjo" -tilassa. Komponentin oikea toiminta voidaan todeta vertaamalla saatuja tuloksia luotettavien komponenttien tuloksiin. Tätä prosessia käytetään usein äänestyspohjaisissa järjestelmissä, koska riittää, että komponentti suljetaan "varjo" -tilassa lopullisesta äänestyksestä.
Näissä prosesseissa voidaan erottaa kaksi roolia.
Perustuen olettamukseen, että ennaltaehkäisy on parempi kuin parannuskeino , järjestelmään liittyvien tapahtumien määrää vähentävien ohjausprosessien käyttöönotto parantaa saatavuutta. Kaksi prosessia sallivat tämän roolin:
Toteuttamalla nämä kaksi prosessia voidaan välttää monia tapahtumia.
Hajoamisia tapahtuu aina. Tässä vaiheessa palautusprosessi virhetilanteessa on välttämätöntä, jotta palvelu voidaan palauttaa mahdollisimman nopeasti. Tällä prosessilla on oltava yksi tavoite: jotta käyttäjä voi käyttää palvelua mahdollisimman nopeasti. Lopullista korjausta tulisi siksi välttää, koska se vie paljon kauemmin. Tämän prosessin pitäisi siis luoda ongelma kiertotielle.
Korkean käytettävyyden klusteri (vastakohtana laskentaklusterin) on klusterin tietokoneita, joiden tavoitteena on tarjota palvelua välttäen seisokit mahdollisimman paljon.
Tässä on tyhjentävä luettelo UNIX: n klusterointisovelluksista (käynnissä AIX , HP-UX , Linux tai Solaris):
On varmentamislaitokset, kuten Uptime Instituten (joskus kutsutaan "Global Data Center viranomainen" ), joka on määritellyt luokitukset alalla datakeskukset , erottaa neljä erilaista "kolmannet osapuolet", sekä kriteerit sietokykyä .