Principer för design av högtillgängliga IT-lösningar, Björn ... - Pulsen
Principer för design av högtillgängliga IT-lösningar, Björn ... - Pulsen
Principer för design av högtillgängliga IT-lösningar, Björn ... - Pulsen
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Principer</strong> <strong>för</strong> <strong>design</strong> <strong>av</strong><br />
<strong>högtillgängliga</strong> <strong>IT</strong>-<strong>lösningar</strong><br />
…empiri sedan 1990…<br />
<strong>Björn</strong> Rodén<br />
bjorn.roden@pulsen.se
<strong>Björn</strong> Rodén<br />
http://linkedin.com/roden<br />
• MSc, BSc, BCSc, DiplCSc, DiplSSc [Informatik & Dat<strong>av</strong>etenskap]<br />
• IBM Certified Infrastructure Systems Architect (ISA)<br />
– En <strong>av</strong> idag fem i Norden och under 200 World Wide<br />
• Certified TOGAF Architect<br />
• Certified PRINCE2 Project Manager<br />
• Certified IBM AIX Technical Expert, IBM Specialist & IBM Technical Leader:<br />
POWER, IBM Open Storage, TSM/ADSM, PowerHA/HACMP, PowerVM/SP samt IBM ISS, HP, Solaris,<br />
Linux, XEN – 1994-2010<br />
• Författare <strong>av</strong> fem IBM RedBooks, en RedWiki och granskare <strong>av</strong> flera<br />
• Presentatör vid flera IBM Technical University (POWER)<br />
+ Design, planering och in<strong>för</strong>ande <strong>av</strong> <strong>högtillgängliga</strong> <strong>lösningar</strong>, stabila och<br />
säkrade system genom åren <strong>för</strong> bla:<br />
Sony Ericsson, IKEA, TietoEnator, Volvo, Jämtlands Läns Landsting, Telia, Tetra Pak, mfl mfl<br />
2
Utmaningar och behov<br />
Informationshantering <strong>för</strong> verksamhetsnytta strävar efter att…<br />
Säkerställa behövlig servicenivå (SLO/SLA)<br />
Hantera risker (hantera, negligera, över<strong>för</strong>a)<br />
Sänka kostnader (CAPEX/OPEX)<br />
…genom kontrollerad<br />
kostnadsutveckling <strong>för</strong><br />
behövlig servicenivå med<br />
acceptabel risk<br />
Riskaccept<br />
Hantera/Negligera<br />
Serviceaccept<br />
SLO/SLA<br />
Kostnadsaccept<br />
CAPEX/OPEX<br />
3
Informationshantering <strong>för</strong><br />
verksamhetsnytta<br />
Verksamhetens möjliga nytta <strong>av</strong> vital information – <strong>för</strong> att fatta<br />
beslut eller ut<strong>för</strong>a dagligt arbete – begränsas <strong>av</strong> kvalitetsbrister i<br />
<strong>IT</strong>-miljöns…<br />
Informationstillgänglighet<br />
Informationssäkerhet<br />
Informationsbevarande<br />
Lag- och <strong>för</strong>ordningsefterlevnad<br />
Men även i befintlig…<br />
Arkitektur och teknologi<strong>för</strong>utsättning<br />
Teknologikompetens och arbetsprocesser<br />
4
Service – Risker – Kostnader<br />
De flesta näringsverksamheter kräver tillgång till behövlig<br />
information i rätt tid <strong>för</strong> att fungera effektivt. Att vara utan<br />
information och informationssystem kan bli både dyrt och<br />
besvärande - o<strong>av</strong>sett om det sker planerat eller ej…<br />
<strong>IT</strong>-funktioner som lagrar, skyddar, hanterar och<br />
tillgängliggör verksamhetens information och data <strong>för</strong><br />
att den skall vara tillgänglig när så behövs,<br />
<strong>för</strong> att minska risker <strong>för</strong><br />
stilleståndsskostnader och minska<br />
hanteringskostnader.<br />
Not: Information Technology Infrastructure Library (<strong>IT</strong>IL) definierar: “the goal of Availability<br />
Management as optimizing the capability of the <strong>IT</strong> infrastructure and supporting organization to deliver<br />
a cost-effective and sustained level of service <strong>av</strong>ailability that enables the business to satisfy its<br />
objectives”.<br />
5
Tillgänglighet – Pålitlighet – Stabilitet<br />
Tillgänglighet (<strong>av</strong>ailability) <strong>av</strong>ser längden på kontinuerligt<br />
nyttjande <strong>av</strong> informationstillhandahållandetjänster <strong>för</strong> sina syften.<br />
Pålitlighet (reliability) <strong>av</strong>ser medelvärdet <strong>av</strong> funktionstid innan fel<br />
inträffar – komponentfeltolerans anges med MTBF (Mean Time Between<br />
Failure). En komponents <strong>för</strong>måga att återta <strong>av</strong>bruten funktionalitet kan anges<br />
som MTTR (Mean Time to Recover). För komponenter som inte repareras blir<br />
MTBF = MTTF (Mean Time To Failure). För statistiskt exponentiell distribution<br />
blir pålitligheten <strong>av</strong> MTBF/MTTF ~37%, med normal<strong>för</strong>delning 50%.<br />
Stabilitet är en funktion <strong>av</strong> MTBF(mod) och MTTR:<br />
Stabilitet =<br />
EXEMPEL:<br />
- MTBF=300.000h & MTTR=20h (felanmälan, planering, byte, € verifiering)<br />
- 300.000 * 37% => 110.000/(110.000+20) = 99.982%<br />
MTBF<br />
MTBF + MTTR<br />
- MTTR=20s => 99.99999% (typvärde <strong>för</strong> EtherChannel/LinkAggregation Failover)<br />
6
Systematiskt tillvägagångssätt<br />
Systematiskt tillvägagångssätt:<br />
1. Identifiera skyddsvärde & stilleståndskostnader<br />
2. Identifiera hot & risker<br />
3. Besluta acceptnivå (behov, kr<strong>av</strong>, risk & servicenivå)<br />
4. Genom<strong>för</strong> kontinuitets<strong>design</strong> – upprätta SLO<br />
5. Verkställ kontinuitets<strong>design</strong><br />
6. Verifiera kontinuitets<strong>design</strong><br />
7. Validera SLO<br />
7
1<br />
SKYDDSVÄRDE &<br />
STILLESTÅNDSKOSTNAD<br />
8
Tillgänglighetsnivåer<br />
Stilleståndstid = otillgängligt<br />
1. Grundläggande tillgänglighet<br />
• Vanligtvis baserat på enkelt system utan intern redundans.<br />
2. Utökad tillgänglighet<br />
• Vanligtvis baserat på enkelt system med viss intern redundans,<br />
alternativt tillgängliga reservdelar/extra system.<br />
3. Hög tillgänglighet<br />
• Vanligtvis <strong>design</strong>ad teknisk plattform med intern och<br />
extern redundans (HW, SW, konfiguration & drift).<br />
4. Kontinuerlig tillgänglighet<br />
• Fabrikskonstruerad teknisk plattform med 100% intern<br />
tillgänglighet, alternativt distribuerad feltolerans med eller nära<br />
100% tillgänglighet.<br />
10
2<br />
HOT OCH RISKER<br />
12
Risk<br />
Risk kan, i teknisk bemärkelse, definieras som<br />
sannolikheten <strong>för</strong> att en specificerad<br />
omständighet (riskkälla) leder till en<br />
specificerad oönskad händelse eller effekt<br />
under en angiven tidsperiod.<br />
En risk som kan <strong>för</strong>verkligas utgör ett hot<br />
Hot är en varning om möjlig obehaglig följd, dvs möjligt <strong>för</strong>vekligande <strong>av</strong><br />
en oönskad händelse(-er)<br />
Källa: Nationalencyklopedin, 2009, http://www.ne.se/lang/risk (mod)<br />
Nationalencyklopedin, 2009, http://www.ne.se/sve/hot/O184636<br />
13
Hotbild<br />
Katastrof(1): ”Mycket stor<br />
olycka med omfattande<br />
materiell <strong>för</strong>ödelse efter<br />
vilken man har svårt att<br />
tänka sig ett återställande”<br />
Flyg<br />
Tåg<br />
Brand<br />
Strömbortfall<br />
Översvämning<br />
Avfallsutsläpp<br />
Källa: (1) Nationalencyklopedin, 2009, http://www.ne.se/sve/katastrof (mod)<br />
Se även: RSOE EDIS [http://hisz.rsoe.hu/alertmap/index.php?smp=&lang=eng]<br />
Tsunami<br />
Storm/Orkan<br />
Jordskred<br />
Jordbävning<br />
Sabotage<br />
Explosion<br />
Sjukdom Epidemi<br />
14
Hot mot enskild datacentral<br />
Strömrelaterat (dipp, spik, bortfall)<br />
Stormskador<br />
Översvämmning<br />
Brand och explosion<br />
Jordskred/jordbävning<br />
Övrigt<br />
0 5 10 15 20 25 30 35<br />
Källa: Contingency Planning Research [www.contingencyplanningresearch.com/costofdowntime.htm]<br />
15
Hot mot enskilt system<br />
Planerat underhåll<br />
Applikationsfel<br />
Operatörsfel<br />
Maskinfel<br />
Systemprogramfel<br />
Miljöpåverkan (ström, värme, vatten, …)<br />
Annat<br />
Källa: Standish Group Research Note International DARTS<br />
0 5 10 15 20 25 30<br />
16
Hot mot specifik information<br />
Inte att <strong>för</strong>glömma intrång…<br />
<strong>för</strong> att ut<strong>för</strong>a sabotage/<strong>för</strong>störa/<strong>för</strong>hindra<br />
• Maskar, trojaner, virus, malware, EDOS…<br />
<strong>för</strong> att ut<strong>för</strong>a illegal Business Intelligence<br />
• <strong>av</strong> egen eller annans personal…<br />
• <strong>av</strong> egen vilja, genom misstag eller otillbörlig påtryckning<br />
17
Hot mot högtillgänglighetsfunktionalitet<br />
Beakta att bristfällig kompetens <strong>för</strong> <strong>design</strong>,<br />
planering, in<strong>för</strong>ande, underhåll, ledarskap &<br />
kontroll kan påverka riskgraden…<br />
Vid utveckling <strong>av</strong> specifik lösning<br />
Under drift <strong>av</strong> specifik lösning<br />
Under <strong>för</strong>ändringshantering i <strong>IT</strong>-miljön<br />
Vid <strong>av</strong>veckling <strong>av</strong> specifik lösning<br />
18
3<br />
ACCEPTNIVÅ<br />
19
Skyddsvärde vis-a-vis lösningskostnad<br />
Lösnings<br />
kostnader<br />
Behov<br />
&<br />
kr<strong>av</strong><br />
Balans<br />
Risker<br />
Stillestånds<br />
kostnader<br />
20
Skyddsvärde vis-a-vis lösningskostnad<br />
Kostnad<br />
Accepterad<br />
totalkostnad<br />
(Balans)<br />
Funktionåterställningstid"<br />
Stilleståndskostnader<br />
(Skyddsvärde)<br />
Lösningskostnader<br />
21
4<br />
KONTINU<strong>IT</strong>ETSDESIGN<br />
22
Designparametrar<br />
Behov, kr<strong>av</strong>, riskaccept &<br />
budget<br />
Recovery Time<br />
Objective<br />
(RTO)<br />
Recovery Point<br />
Objective<br />
(RPO)<br />
Network Time Objective (NTO)<br />
Power Time Objective (PTO)<br />
• Verksamhetens behov, kr<strong>av</strong>, riskaccept & budget<br />
• Hur länge kan system vara ur drift?<br />
• Acceptabel återställningstid<br />
• Hur mycket data kan undvaras?<br />
• Acceptabel återställningstillstånd<br />
• Hur länge kan nätverket vara ur drift?<br />
• Hur länge kan el-matningen vara borta?<br />
23
Informationsflöde <strong>för</strong>enklat<br />
Datalevererande<br />
system<br />
Informationsflöde i verksamheten<br />
V<strong>IT</strong>ALT<br />
SYSTEM<br />
Data-<br />
mottagande<br />
system<br />
Tillgänglighet Tillgänglighet Tillgänglighet<br />
Buffertid Buffertid<br />
24
Kontinuitets<strong>design</strong><br />
Säkra<br />
arbetsprocesser,<br />
mätning, kontroll<br />
och validering <strong>av</strong><br />
SLO i SLA<br />
MTBF<br />
kontinuitet<br />
[servicenivå 1]<br />
Katastrof<br />
kontinuitet<br />
[servicenivå 3]<br />
Funktions<br />
kontinuitet<br />
[servicenivå 2]<br />
25
MTBF kontinuitet<br />
MTBF kontinuitet syftar till att korrelera ett <strong>IT</strong>systems<br />
skilda komponenters enskilda<br />
funktionalitetspålitlighet och stabilitet <strong>för</strong> att uppfylla<br />
verksamhetens tillgänglighetskr<strong>av</strong>.<br />
– <strong>IT</strong>-system <strong>för</strong> informtionstillhandahållande består <strong>av</strong> distinkta<br />
komponenter, vardera med specifik MTBF som anger ett<br />
tillverkarspecificerat medelvärde <strong>för</strong> hur lång tid<br />
respektive komponent kan vara funktionsduglig.<br />
– Komponentpåverkan analyseras genom hierarkisk felträdsanalys,<br />
där enskilda grenars MTBF/MTTF stabilitet kan sammanräknas.<br />
– Kritisk led genom ett felträd analyseras genom identifiering <strong>av</strong><br />
lägsta MTTF <strong>för</strong> en vital komponentgren eller stabilitet
Systemöversikt <strong>för</strong>enklat<br />
Adapter<br />
Kablering<br />
Växel<br />
Kablering<br />
Adapter<br />
Lagring<br />
Lagring<br />
Adapter<br />
Kablering<br />
Växel<br />
Kablering<br />
Adapter<br />
Lagring<br />
Kablering<br />
Växel<br />
Kablering<br />
FW/IPS<br />
Internet leverantör<br />
Nätverk<br />
Adapter<br />
Kablering<br />
Växel<br />
Kablering<br />
FW/IPS<br />
Internet leverantör<br />
V<strong>IT</strong>ALT SYSTEM<br />
Ström<br />
UPS<br />
Matning<br />
El-leverantör<br />
Kompetens<br />
Antal<br />
Tillgänglighet<br />
Personal<br />
Systemadmin<br />
Instruktioner<br />
Kontroll<br />
Processer<br />
Aktuell dokumentation<br />
CMDB<br />
Discovery Mapping<br />
Identifiera och eliminera enskilda vitala komponenter <strong>för</strong><br />
stabila och <strong>högtillgängliga</strong> system (Single Points Of Failure)<br />
27
Klustersystemprinciper<br />
Feltolerant [kontinuerlig tillgänglighet]<br />
• Ett feltolerant system har minst dubblerade komponenter och mikrokod/programvara<br />
som kan hantera inträffade fel utan <strong>av</strong>brott i service (FT/Distribuerad FT).<br />
Samtidigt aktiv [hög tillgänglighet]<br />
• Ett redundant kluster där alla noder tillhandahåller samma service (app-kluster).<br />
Aktivt beredd [~hög tillgänglighet]<br />
• En likvärdig reservnod är aktivt beredd att överta primärnodens service (nod-kluster).<br />
Passivt beredd [utökad tillgänglighet]<br />
• En likvärdig reservnod är passivt redo att överta primärnodens service (nod-kluster).<br />
Passiv reserv [utökad tillgänglighet]<br />
• En likvärdig reservnod finns tillgänglig att, efter iordningsställande (fysiskt/<strong>av</strong>tal).<br />
29
Jäm<strong>för</strong>else <strong>av</strong> olika <strong>lösningar</strong><br />
Jäm<strong>för</strong>elsepunkt Komplexitetsfaktor / kostnad<br />
Komponentkostnad<br />
Applikationskostnad<br />
Genom<strong>för</strong>barhetsstudie<br />
Design & arkitektur<br />
Projektering<br />
Projektledning<br />
Installation & konfiguration<br />
Verifiering<br />
Dokumentation<br />
Kompetensutveckling<br />
Underhållskostnad per år<br />
Validering SLO (+6mån)<br />
Lösning#1 Lösning#2<br />
Komplexitets faktor<br />
estimat beroende på<br />
respektive specifika<br />
lösnings komplexitetsnivå<br />
utifrån produkternas<br />
mognad, antal kända<br />
produktionsin<strong>för</strong>anden,<br />
kännedom om berörda<br />
applikationer och<br />
datalagringssystem samt<br />
underhållskr<strong>av</strong> från<br />
respektive produkt på den<br />
mottagande organisationen<br />
och den mottagande<br />
organisationens <strong>för</strong>måga.<br />
30
5 & 6 & 7<br />
PLANERA, VERKSTÄLL,<br />
VERIFIERA & VALIDERA<br />
31
Planera & verkställ<br />
• Planera<br />
– Upprätta övergripande projektplan<br />
• tid, resurs, risk, kvalitet, kommunikation, ändringshantering<br />
– Granska <strong>av</strong>talade måls mätbarhet<br />
– Upprätta tekniskt styrdokument & kompetensbehovskarta<br />
– Upprätta 1sta etapplan detaljerat med verifieringstester<br />
– Marginaler <strong>för</strong> verifiering & RTP (estimera & dubblera)<br />
• Verkställ<br />
– Säkra att rätt kompetens kan verka effektivt<br />
– Mindre daglig direktstyrning -> längre kalendertid<br />
– Detaljera respektive etapplan i god tid<br />
– För ersättningssystem –> driftmigreringsplanering & simulering<br />
– Etapper:<br />
• 1.Fysiskt, 2.Logiskt, 3.Applikation, testdata & applikationsverifiering, 4.Prep RTP,<br />
5.RTP verifiering, 6.Driftsättning, 7.Validering (+6mån)<br />
32
Verifiera & validera<br />
• Verifiera<br />
– För att bekräfta tillgänglighetsfunktionalitet<br />
1. Fysiska system, komponenter & nätverk (LAN/SAN)<br />
2. Logiska system & kommunikation<br />
3. Applikationer & logiska kopplingar<br />
4. Felscenariofunktionalitet<br />
5. RTP<br />
• Validera<br />
6. Kompetensnivå<br />
– För att bekräfta verksamhetsnyttan samt ROI och TCO<br />
– Efter drift i ca 6-12 månader<br />
– Kompetensnivå<br />
33
Framtiden<br />
Var misstänksam mot konsulter som inte<br />
ställer irriterande många frågor –svaren<br />
behövs <strong>för</strong> en seriös <strong>design</strong> och planering.<br />
Gör rätt från början!<br />
Skyddsvärde?<br />
– 24/7/365 & 100% => FT/DFT<br />
– 24/7/365 & 99.999% => BU<br />
34
Nästa steg med <strong>Pulsen</strong><br />
Kontakta din säljare<br />
– Hitta behoven och utmaningarna<br />
Vision och strategi<br />
– Genom<strong>för</strong> en policy- och strategistudie<br />
Effektmål <strong>av</strong>seende ekonomi, organisation och påverkan<br />
Arkitektur, <strong>design</strong>, revision & kvalitetssäkring<br />
– Kontakt gärna mig <strong>för</strong> råd & dåd <br />
35
Frågor……..<br />
<br />
36
Change language