Palveluiden priorisointi osana konesalin jatkuvuussuunnitelmaa

GN4 Kampus-projektissa julkaistu englanninkielinen versio

Johdanto

Kampusverkoista on tullut erittäin tärkeitä ja kriittisiä koko kampuksen toiminnan kannalta. Perusverkkopalveluiden, kuten IP-osoitteiden, nimipalvelun ja dynaamisen osoitehallinnan (DHCP) lisäksi verkkopalveluina tarjotaan sähköpostipalvelua, tulostuspalveluita, tallennuspalveluita sekä erilaisia opintohallinnon tai taloushallinnon tarvitsemia tietojärjestelmiä, kuten opintosuoritusten kirjausjärjestelmä, työajanseuranta tai laskujen maksujärjestelmä. Palveluita tarjotaan joko fyysisiltä tai virtualisoiduilta palvelimilta. Tietoliikenne taas hoidetaan esimerkiksi reitittimillä, kytkimillä, palomuurein. Kampusverkon sydän on konesali, missä nämä kaikki kampusverkon kriittiset palvelut ja niiden tarvitsemat laitteet sijaitsevat. Yksittäinen konesali yleensä sisältää useita erilaisia laitteita.

Toimiakseen tarkoituksen mukaisesti, konesali tarvitsee jonkinlaisen jäähdytysjärjestelmän, jotta lämpötila ei nouse konesalissa oleville laitteille liian korkeaksi. Jäähdytyksen lisäksi konesali tarvitsee tehokkaan sähkönsyöttöjärjestelmän, jotta kaikille laitteille riittää oikean tehoista virtaa. Nämä kaksi järjestelmää ovat konesalin kaikkein kriittisimmät järjestelmät. Jos näihin järjestelmiin tulee häiriötilanne, on ennalta tiedettävä kuinka toimitaan. Tällaisia suuria poikkeustilanteita varten on laadittava ennalta jatkuvuussuunnitelma (business continuity plan) missä kerrotaan kuinka toimitaan.

Tämä Parhaat Käytännöt -dokumentti keskittyy palveluiden sekä palvelualustojen priorisointiin osana jatkuvuussuunitelmaa, kun konesali kohtaa ennalta arvaamattoman suuren poikkeustilanteen, kuten sähkökatkon eikä varavoimaa ole heti käytettävissä, tai jäähdytysjärjestelmään tulee vika, jota ei pystytä hetkessä korjaamaan. Tällaisessa poikkeustilanteessa voidaan joutua ajamaan alas suuri joukko palveluita. Dokumentti ei listaa kaikkia asioita täydellisesti, vaan antaa esimerkkejä, mistä on hyvä lähteä liikkeelle pohtimaan dokumentointia, ohjeistusta sekä toimintaprosesseja omassa toimintaympäristössä osaksi jatkuvuussuunnitelmaa.

Dokumentoi

Kaiken a ja o on dokumentoida konesalin koko tekninen ympäristö sekä prosessit. Dokumentointityökaluksi suositellaan jotain sähköistä järjestelmää, jotta asioiden päivittäminen olisi mahdollisimman helppoa. Lisäksi sähköisissä järjestelmissä voi olla mahdollista linkittää asioita useaan eri paikkaan, jolloin tiedon päivittäminen yhteen paikkaan riittää. Asioita voi dokumentoida esimerkiksi CMDB-järjestelmään (Configuration Management Database), joita on saatavilla sekä open source- että kaupallisina sovelluksina. Asioita voi dokumentoida useaan eri järjestelmään, mutta tällöin pitää muistaa huolehtia siitä että tiedot päivittyvät kaikkiin eri paikkoihin, joita asia koskettaa.

Dokumentoinnista on myös hyötyä poikkeustilanteissa, esimerkiksi jos tapahtuu laiterikko. Tällöin hallitussa ja dokumentoidussa ympäristössä varapalvelun käyttöönotto sujuu nopeammin kuin hallitsemattomassa ympäristössä. Lisäksi hallitussa ympäristössä on dokumentoituna tieto, mitä tarvitaan kun palvelu tarvitsee lisäresursseja, kuten lisää levytilaa, prosessointikapasiteettia, tiedonsiirtonopeutta, enemmän virtaa tai jäähdytystä.

Käytä dokumentoinnissa standardoituja termejä ja käsitteitä. Tällöin niitä on helpompi kuvata FitSM/ITIL-mukaisiin prosesseihin (lähteet 1 ja 2).

Dokumentoi toimintaympäristöt ja niiden palveluntarjoamismahdollisuudet mahdollisine rajoitteineen. Tietojärjestelmien arkkitehtuuri sisältää usein edustapalvelimen tai useita edustapalvelimia ja taustalla tieto sijaitsee yhdessä tai useammassa tietokantapalvelimessa. Tällaisessa ympäristössä on tärkeää tietää palvelinten riippuvuudet toisiinsa, jotta mahdolliset verkosta ja palvelimista aiheutuneet vikatilanteet saadaan hallittua ja palvelu saadaan taas toimintakuntoon nopeasti. Selvitä ja dokumentoi siis kaikkien laitteiden riippuvuudet toisiinsa. Tässä työssä kuvien piirtämisestä voi olla suurta hyötyä.

Dokumentoi miten verkon ja palveluiden varmistukset on tehty, mitkä laitteet tai järjestelmät varmentavat toisiaan ja missä niin sanotut SPOF-kohdat (Single Point of Failure) ovat. Lisäksi dokumentoi mitä manuaalisia toimenpiteitä mahdollisesti tarvitaan, jos kaikkea ei ole ollut järkevää automatisoida. Ilman kattavaa dokumentoitua tietoa mitä laitteita, järjestelmiä ja laitetiloja on käytettävissä, on melko mahdotonta saada hallittua asioita varsinkaan isoissa poikkeustilanteissa.

Dokumentoinnin pitää sisältää myös tiedot siitä kuka tekee päätöksiä toimenpiteistä, ketkä suorittavat päätetyt toimenpiteet ja miten asioista viestitään loppukäyttäjille. Kaikille henkilöille pitää olla saatavilla ajantasaiset yhteystiedot sekä tiedot varahenkilöistä.

Pilko konesaliympäristö pienempiin osiin/kategorioihin, jotta hahmotat helpommin dokumentoitavat asiat. Alla on esimerkkinä konesaliympäristöä listattu kolmen tasoisena.

Laitetilainfrastruktuuri

Dokumentoi käytettävissä olevat laitetilat, niiden fyysinen koko, kantavuus, sähkönsyötöt (vaiheet ja tehot), jäähdytyskoneet sekä varavirran syötöt. Nimeä tilat ja poikkeustilanteita varten laadi kulkuohjeistus, joka pitää sisällään mm. tiedot henkilöistä keillä on sallittu pääsy tiloihin. Mikä on tilan maksimilämpökuorma sekä jäähdytysteho. Jos etähallinta palveluihin katkeaa, tee ohjeet kuinka laitetiloihin päästään ja sitä kautta kiinni palvelun hallintarajapintaan. Liitteessä 1 on listattu lisää esimerkkejä dokumentoitavista asioista.

Laitetilainfrastruktuurin häiriöt voivat aiheuttaa erittäin laajamittaisia vaikutuksia tilassa tuotettaville palveluille. Häiriöt voivat johtua erilaisista vikatilanteista, mutta myös suunnitellut huoltotilanteet nostavat palveluiden jatkuvuuden riskitasoa merkittävästi. Jäähdytysjärjestelmien vikaan tai ulkoisen sähköverkon katkoon voidaan pyrkiä varautumaan laitteiston priorisoinnilla ja alasajosuunnitelmalla. Salin oman sähkönsyötön vika voi kuitenkin aiheuttaa suoraan IT-laitteistolle näkyvän sähkökatkon osassa tilaa, tai jopa koko tilassa. Tällaisesta tilanteesta toipuminen voi vaatia erityistoimenpiteitä, esim. varmistuksia etteivät laitteet käynnisty automaattisesti väärässä järjestyksessä. Kaluston hallitsematon alasajo saattaa aiheuttaa ongelmia niin laitteistolle kuin ohjelmistoillekin.

Verkkoinfrastruktuuri

Dokumentoi toimintaympäristön kaikki reitittimet, kytkimet, palomuurit sekä mahdolliset muut tietoliikennelaitteet. Mitä laitteita ne ovat, mitä palveluita niillä tuotetaan, miten ja millä niitä hallitaan sekä monitoroidaan. Millainen kapasiteetti niissä on, käytetäänkö jotain automaatiota joissain asetuksissa jne.

Yhtenä lopputuloksena pitäisi tulla lista kaikista tietoliikennelaitteista, niiden ominaisuuksista, toistensa riippuvuuksista ja hallinnasta. Lista voi tarkoittaa tässä myös laiterekisteriä.

Laitteet kannattaa tarroittaa yksilöivällä tunnuksella, jotta ne löydetään konesalissa tarvittaessa nopeasti. Palomuureista kannattaa dokumentoida myös säännöt ja niiden ylläpitoprosessi. Verkkopalveluiden tarvitsemat portit ja protokollat ovat tärkeitä tietää, varsinkin jos palvelu siirretään esimerkiksi poikkeustilanteessa konesalista toiseen.

Tietoliikenneyhteyksistä kannattaa dokumentoida verkkotopologia sekä fyysisesti miten laitteet on kytketty toisiinsa. Verkoista tehty dokumentaatio pitää sisällään osoiteavaruudet mitä on käytössä millekin palvelulle. Lisäksi miten hallintayhteydet, VLANit ja reititykset on rakennettu. Lisää esimerkkejä dokumentoitavista asioista, on kerrottu liitteessä 2.

Palvelin- ja palveluinfrastruktuuri

Dokumentoi virtuaali- sekä rautapalvelimet ja niiden fyysiset ominaisuudet: CPU, muistimäärä, powereiden lukumäärä, onko sisäisiä levyjä jne. – vastaavia tietoja kuin verkkolaitteista. Dokumentoi palvelinten sijainti, missä konesalissa ja telineessä ne sijaitsevat. Dokumentoi käytettävät palvelut ja niiden riippuvuudet toisista palveluista, esimerkiksi palvelun riippuvuus levypalvelimista. Lisäksi dokumentoi toimiiko palvelu virtuaalipalvelimella. Jos kyllä, niin millä/minkä nimisellä. Jos palvelu tarvitsee oman fyysisen palvelimen, dokumentoi palvelun tarvitsemat riippuvuudet muista palvelimista sekä verkkolevyistä.

Dokumentoi tietoliikenteen kannalta tärkeimmät palvelut: Nimipalvelu, DHCP, NTP (sen fyysiset palvelimet, missä sijaitsevat, miten laitteet ja yhteydet on varmennettu). Lisää esimerkkejä dokumentoitavista asioista on listattu liitteissä 3, 4 ja 5.

Yhtenä dokumentoinnin osana pitäisi pystyä tekemään lista palveluista missä järjestyksessä niitä voi ajaa alas ja nostaa ylös. Tee omat ohjeet kullekin palvelulle miten ne saa ajettua alas ja nostettua ylös sekä testattua toimivuus.

Kun dokumentointi on saatu tehtyä, muista tiedotus, jotta tarvittavat osapuolet löytävät dokumentoinnin sekä ohjeet. Testaa myös että henkilöt pääsevät kirjautumaan tarvittaviin järjestelmiin.

Priorisoi

Kun olet saanut dokumentoitua konesalissa olevien laitteiden ja palveluiden riippuvuudet toisiinsa, ryhmittele ne ja tee priorisointi jokaisen ryhmän sisällä. Esimerkiksi ryhmät voisivat olla:

1. virtuaalipalvelimet ja standby-palvelimet
2. virtuaalialustat
3. fyysiset palvelimet
4. varmuuskopiojärjestelmät
5. levyjärjestelmät ja tietokantapalvelimet
6. kriittiset perusverkkopalvelut (DNS,DHCP, NTP, AD,...)
7. tietoliikennelaitteet

Seuraavaksi sijoita laitteet listan ryhmiin. Muista tarkistaa dokumentoinnista riippuvuudet, jotta esimerkiksi edustapalvelimet ajetaan alas ennen taustapalvelimia. Ryhmien sisällä priorisoi saman ryhmän laitteet keskenään. Mieti tässä kohtaa mikä laite on kunkin ryhmän tärkein ja anna sille suurempi numero kuin vähemmän tärkeälle laitteelle. Jos käytössä on useita konesaleja, niin huomioi myös tilanteet joissa palvelu on mahdollista siirtää varakonesaliin.

Seuraavassa esimerkkilistauksessa on virtuaalipalvelimet "testipalvelin" sekä "asiakaspalvelu2" toimivat Plade1-virtuaalialustalla ja "asiakaspalvelu1" on Plade2-alustalla. Näin ollen nämä palvelimet tulee ajaa alas ennen kuin niiden alusta. Alla olevassa esimerkissä järjestys on priorisoitu siten, että vähiten haittavaikutuksia tulee ajamalla "testipalvelin" ensimmäisenä ja "asiakapalvelu2" toisena alas.

1. virtuaalipalvelimet
   1.1. testipalvelin
   1.2. asiakaspalvelu2
   1.3. asiakaspalvelu1
2. virtuaalialustat
   2.1. Plade1
   2.2. Plade2
3. fyysiset palvelimet
4. ...

Priorisointia kannattaa miettiä eri näkökulmista, mutta kannattaa valita vain 1-2 niin sanottua suurta linjaa joille kummallekin tekee omat priorisointilistat.

Priorisointiperusteena voi olla sähkönkulutus, asiakkaan kanssa tehty palvelutason sopimus, loppukäyttäjien lukumäärä, palvelun vaikutus toisiin kriittisempiin palveluihin jne. Erilaisia näkökulmia voidaan keksiä helposti ja niitä kannattaa soveltaa varsinkin ryhmien sisällä tapahtuvassa priorisoinnissa. Alla on esitetty kaksi esimerkkiä, joissa suuriksi linjoiksi on valittu "Pelataan aikaa" ja "Ajetaan koko konesali alas".

Esimerkki 1: Pelataan aikaa

Tässä tapauksessa konesalissa on suuri poikkeustilanne, esimerkiksi sähkökatko, jonka pituutta ei voida tarkasti tietää. Mutta jonkinlaisia tietoja tai arvauksia sen kestosta pystytään ehkä tekemään esimerkiksi energialaitoksen tiedotteen perusteella. Jos konesalissa on mahdollisuus varavoimaan, mutta varavoimakone on sovittu sopimuksin toimitettavan paikan päälle tietyllä viiveellä, ei ole järkevää ajaa koko konesalia alas. Tällöin priorisoidaan ne palvelut, jotka vievät eniten virtaa ja/tai asiakkaan kanssa sovitut palveluntasosopimukset, jotka antavat mahdollisuudet ajaa tällaiset palvelut alas ensimmäisten joukossa.

Kun osa palveluista on ajettu alas, seurataan varavoiman tilaa (UPS) sekä jäähdytystä ja arvioidaan jatketaanko palveluiden alasajoa vai voidaanko jäädä odottamaan sähköjen palautumista tai varavoimankoneen kytkentää.

Esimerkki 2: Ajetaan koko konesali alas

Tässä tapauksessa konesalin poikkeustilanne on niin suuri ja vakava, että kaikki laitteet on ajettava alas. Tällöin seurataan tarkasti aiemmin tehtyä priorisointilistaa ja ajetaan palveluita alas sen mukaisesti. Joitain palveluita voitaneen ajaa alas rinnakkain yhtä aikaa, mutta tällöin on erittäin tärkeää seurata riippuvuussuhteita, jotta ei mennä listassa liian edelle ja ajeta alas jonkun toisen palvelun alustaa missä vielä on palveluita käynnissä.

Tee jokaiselle konesalille oma priorisointilista. Listassa kokonaisuuksien riippuvuudet voi merkitä esimerkiksi väreillä (käytetty ao. taulukossa) tai tekemällä tätä varten oman sarakkeen ja siihen tehdä selvät merkinnät. Muista päivittää dokumentaatiota säännöllisin välein. Ota dokumentointi osaksi palveluprosesseja, jotta se linkittyy luontevasti osaksi muuta toimintaa. Esimerkiksi uuden palvelun pystytyksen yhteydessä on hyvä tarkistaa, että dokumentaatio ovat ajan tasalla ja sekä mm. pääsynhallinta toimii oikein.

Alla on esimerkki priorisointitaulukosta. Esimerkissä pystytään seuraamaan listaa järjestelmällisesti ryhmästä toiseen (numerot ovat kasvavassa järjestyksessä), mutta todellissa konesaliympäristössä voidaan joutua hyppimään eri ryhmien välillä. Tärkeää onkin miettiä miten priorisoinnin merkitsee listaan, jotta se on helposti ja nopeasti luettava ja seurattava eri tilanteissa.

Esimerkkitaulukko priorisointilistasta:

Taulukon sarakkeita "Ajettu alas" sekä "Nostettu ylös" voidaan käyttää apuna listaa läpikäydessä. Laittamalla rastin kulloinkin kyseisen palvelun ruutuun, nähdään nopeasti kokonaistilanne sekä pystytään seuraamaan ja valmistelemaan seuraavia tarvittavia toimenpiteitä.

Kun konesalin poikkeustilanne on ohitse, on palveluiden ylösajo nopeaa, kun voidaan seurata alasajoon käytettyä priorisointilistaa takaperin. Palveluiden käynnistäminen tapahtuu tällöin myös hallitusti. Kun palvelut on saatu käynnistettyä, on niiden toimivuus muistettava testata. Lisäksi poikkeustilanteesta on hyvä tiedottaa käyttäjiä, viimeistään silloin kun tiedetään syyt tilanteeseen - jos tiedotusta ei ole jo pystytty tekemään poikkeustilanteen aikana.

Sijoita priorisointilistat sekä dokumentaatio paikkaan, josta konesalihenkilöstö/ylläpitäjät löytävät ne nopeasti. Jos käytetään jotain sähköistä järjestelmää, varmista sen toimivuus myös massiivisessa vikatilanteessa (esim. koko konesali vailla sähköä). Jos lista on suhteellisen lyhyt, siitä voi säännöllisin väliajoin printata paperiversion. Muista myös kouluttaa konesalihenkilöstöä tarvittavien toimenpiteiden suorittamiseen.

Poikkeustilanteessa

Kun yllättävä poikkeustilanne kohtaa konesalin, pysy rauhallisena. Pyri selvittämään tilanteen syy ja arvioi sen mahdollinen kesto. Tiedota konesalihenkilöstöä sekä tahoja joita asia koskettaa. Varaudu siirtämään palveluita varakonesaliin. Jos tilanne jatkuu, tee päätös mitä priorisointilistaa aloitetaan toteuttamaan. Seuraa priorisointilistaa ja ala ajamaan palveluita alas suunnitelmien mukaisesti.

Kun tilanne on ohitse, nosta palvelut takaisin seuraamalla priorisointilistoja.

Ole varovainen poikkeusten/väliaikaisten ratkaisujen kohdalla. Ne helposti jäävät pitkäksi aikaa elämään verkkoon ja voivat luoda uusia riippuvuuksia joista voi olla hankala päästä eroon.

LIITE 1: Tila, räkit, jäähdytys, sähköt, varavoima, kuidut/kuparit, kulku ja yhteystiedot

Alla on lueteltu laitetiloihin liittyviä asioita, jotka on hyvä dokumentoida.

• Tilan nimi ja yhteystiedot
• Tilan koko (pituus x leveys x korkeus)
• onko korotettu lattia
  • jos on, niin mikä on sen kantavuus
• Laitetelineet
  • floor plan
  • telineen yksilöllinen tunnus
  • laitetelineen koko (leveys x syvyys x korkeus. lisäksi korkeus RU:na)
  • kantavuus sekä paino
  • minne teline on asennettu laitetilaan
    • jos uusi asennus, niin tehdään asennussuunnitelman (floor plan) mukaisesti
    • suunnitelma sisältää mm. fyysisen paikan/sijoituksen, sähköistyksen, maadoituksen ja kaapeloinnit
  • täyttöaste eli montako RU:ta on käytössä ja käytettävissä tarvittaessa laitetilan kantavuus huomioiden
• Sähkönsyöttö
  
  • nykyiset sähkönsyötöt, niiden vaiheet, sulakkeet
  • pistorasioiden sijainnit
  • pääjakokeskuksen ja sulaketaulujen sijainnit
  • sähkövaiheiden kuormat
  • koko laitetilan sähkökuorma
  • yhteystiedot sähköntuottajalle ja vikapäivystäjälle
• UPS ja varavoima
  • Miten jatkuva sähkönsyöttö (UPS) varavoima on järjestetty
  • Missä ajassa se saadaan käyttöön
  • Kauanko sähkönsyöttö toimii nykyisellä sähkökuormalla UPSin ja varavoimakoneen avulla
    
    • Jos varavoima ei riitä tarvittavalle sähkökuormalle, on palvelimia ajettava alas. Seuraa tällöin priorisointilistaa X.
  • Yhteystiedot varavoimajärjestelmän toimittajalle ja huoltoon sekä vikapäivystykseen
  • Millainen testausjärjestely järjestelmällä on, ja kuka suorittaa säännölliset testit
    • Testattavia asioita: varavoimakoneen moottorin toiminta, käynnistysautomatiikka, sähkönsyötön automaattinen muutos, jne.
    • Varavoimakoneiden osalta on myös seurattava polttoaineen määrää ja laatua (polttoaine voi pilaantua seisoessaan kauan käyttämättömänä)
• Jäähdytys
  • Missä jäähdytyskoneet sijaitsevat
  • Millainen jäähdytysteho niissä on
  • Paljonko jäähdytystehoa tarvitaan tällä hetkellä
  • Yhteystiedot jäähdytyskoneiden toimittajalle ja huoltoon sekä vikapäivystykseen
• Kiinteistötekniikan automaatio, hälytysjärjestelmät ja valvontajärjestelmät
  
  • Millaisista järjestelmistä salin toiminta on riippuvainen, esim. jäähdytyksen ohjausjärjestelmät, sähkönsyötön automaatio
  • Mistä asioista lähtee automaattisia hälytyksiä, kenelle
  • Yhteystiedot em. järjestelmistä vastaaville tahoille/henkilöille
• Kaapelointi
  • Kaapelipaneelien sijainnit, tunnukset ja liitintyypit
  • Valokuitujen tyypit, pituudet ja reitit
  • Kuparikaapelien kategoriat, pituudet ja reitit
• Kulkuohjeet
  • Laitetilan kulkuohjeet
  • Henkilölista yhteystietoineen, kenellä on pääsyoikeudet laitetilaan
  • Mahdolliset muut kulkuun liittyvät ohjeistukset, esim. avainhallinta.
• Turva-/sammutusjärjestelmät sekä valaistus
  
  • Dokumentoi turvajärjestelmien tiedot
  • Ohjeista käyttäjiä näiden järjestelmien käyttöön poikkeustilanteessa

LIITE 2: Verkkolaitteet, fyysiset yhteydet, osoiteavaruudet

Verkkolaitteista kannattaa dokumentoida mm. seuraavat asiat. Dokumentin ulkopuolelle on jätetty laajennussuunnitelma, puuttuvan kaapeli-infran rakentaminen, kaapeleiden värikoodaukset ja (laite)lukitukset.

• Laite
  • Laitetyyppi (reititin, kytkin, palomuuri tms)
  • Nimi (nimipalvelussa/kutsumanimi).
    • Yksilöivä tunnus/nimi kannattaa tarroittaa laitteen kylkeen, jotta se löytyy tarvittaessa nopeasti
• Merkki ja malli
• Kapasiteetti (esim. 1G/10GE, päivitettävyys 100GE:hen tms)
• Hankinta-aika/käyttöönottoaika (takuuaika/elinkaaren arviointi)
• Ohjelmaversio(t) ja mahdolliset ohjelmalisenssit
• Laitteen omistaja/ylläpitäjä(ryhmä) (tietohallinto tms, yhteystiedot, …)
• Fyysinen sijainti (laitetila, floor plan)
• Powereiden lukumäärä ja montako tarvitaan minimissään normaaliin toimintaan
• Maksimi tehotarve, lämpökuorma
• Paino, koko (p x s x k, RU:t)
• Laitevalmistajan/huollon yhteystiedot ja huoltoon/varaosiin liittyvä ohjeistus
• Kytkennät
  • Miten laite on fyysisesti kytketty
  • kaapelipaneelitunnus ja –parit
  • Sähköpistoketunnus ja käytettävä sähkövaihe
• Osoitteet
  • Osoiteavaruudet ja osoitteistus laitteille sekä paikallisverkoille
  • Paikalliset kampuskohtaiset VLAN:t
  • Usean toimipisteen väliset VLAN:t
• Hallinta
  • Laitteen hallintaosoite
  • Hallintaohjelma(t) (CLI, GUI)
  • Käyttäjätunnukset ja niiden käyttöoikeuslaajuudet
  • Shell-tunnukset ja salasanat tai SSH-avaimet
  • Sallitut hostit/verkot hallintayhteyksille kuten SSH, SNMP,  syslog jne.

LIITE 3: Perusverkkopalvelut

Dokumentoi perusverkkopalvelut, joita tarvitaan aivan välttämättä perustietoliikennettä varten. Listaa myös miten palvelut on varmennettu poikkeus-/huoltotilanteita varten. Linkitä tiedot sopivilta osin laitetietoihin jotka on dokumentoitu Liitteessä 2.

• Nimipalvelu (DNS)
  • Palvelimen nimi
  • Fyysinen sijainti
  • Varapalvelintiedot
  • Laitetiedot kytkentöineen (kts. Liite 2)
• DHCP
  • Palvelimen nimi
  • Fyysinen sijainti
  • Varapalvelintiedot
  • Laitetiedot kytkentöineen (kts. Liite 2)
• NTP
  • Palvelimen nimi
  • Fyysinen sijainti
  • Varapalvelintiedot
  • Laitetiedot kytkentöineen (kts. Liite 2)
• AD
• Secure-appliance
• Palomuuri
  • säännöt ja niiden ylläpitoprosessi
  • Laitetiedot kytkentöineen (kts. Liite 2)

LIITE 4: Palvelinrauta, levypalvelimet

Dokumentoi palvelinten lisenssit (sekä mahdollisesti niiden hinnat), storage- ja backup/standby-palvelimet, palvelinyhteydet ja niiden väliset riippuvuudet.

• Palvelinrauta
  • Laitetyyppi (blade tms)
  • Nimi (nimipalvelussa/kutsumanimi).
    • Yksilöivä tunnus/nimi kannattaa tarroittaa laitteen kylkeen, jotta se löytyy tarvittaessa nopeasti
  • Merkki ja malli
  • Kapasiteetti (1G/10G, päivitettävyys 100G:hen tms)
  • Hankinta-aika/käyttöönottoaika (takuuaika/elinkaaren arviointi)
  • Ohjelmaversio(t) ja mahdolliset ohjelmalisenssit
  • Laitteen omistaja/ylläpitäjä(ryhmä) (tietohallinto tms, yhteystiedot, …)
  • Fyysinen sijainti (laitetila, floor plan)
  • Powereiden lukumäärä ja montako tarvitaan minimissään normaaliin toimintaan
  • Maksimi tehotarve, lämpökuorma
  • Paino, koko (p x s x k, RU:t)
  • Laitevalmistajan/huollon yhteystiedot ja huoltoon/varaosiin liittyvä ohjeistus
• Kytkennät
  • Miten ja minne laite on fyysisesti kytketty
  • kaapelipaneelitunnus ja –parit
  • Sähköpistoketunnus ja käytettävä sähkövaihe
• Osoitteet
  • Laitteen hallintaosoite
  • Osoiteavaruudet ja osoitteistus laitteille sekä paikallisverkoille
  • Paikalliset kampuskohtaiset VLAN:t
  • Usean toimipisteen väliset VLAN:t
• Hallinta
  • Laitteen hallintaosoite
  • Hallintaohjelma(t) (CLI, GUI)
  • Käyttäjätunnukset ja niiden käyttöoikeuslaajuudet
  • Shell-tunnukset ja salasanat tai SSH-avaimet
  • Sallitut hostit/verkot hallintayhteyksille kuten SHH, SNMP,  syslog jne.

LIITE 5: Virtuaalisointiympäristöt

Dokumentoi palvelun pystytys ja testaus (varmennukset, riippuvuudet ja varapalveluohjeet, palvelun alasajo, disaster recovery, lisenssit). Dokumentoi hallinta- ja valvonta-asiat.

LYHENTEET

AD       Active Directory

CMDB   Configuration Management Database

CPU     Central Processing Unit

DHCP   Dynamic Host Configuration Protocol

CLI      Command-line Interface

DNS     Domain Naming System

FitSM   Family of standard for lightweight IT service management

GE       Gigabit Ethernet

GUI      Graphical User Interface

IP        Internet Protocol

ITIL     Information Technology Infrastructure Library

NTP     Network Time Protocol

RU       Rack Unit

SNMP   Simple Network Management Protocol

SPOF   Single Point of Failure

SSH     Secure Shell

UPS     Uninterruptible Power Supply

VLAN   Virtual Local Area Network

LÄHTEET:

Lähde1: http://www.fedsm.eu/fitsm

Lähde2: https://en.wikipedia.org/wiki/ITIL