Windows Server 2012 R2 –infrastructure- part 4

Zona de high availability si zona de disaster recovery sunt aspecte critice, practic, asta ar fi unul din motivele existentei unui department IT de administrare/suport retea.

Inainte de a intra putin in topic, mi-am amintit ca am vazut recent parca pe site-ul unui cloud provider, o remarca de genul, ca acum nu mai trebuie sa fim doici pentru echipamente, ci acum ne putem focusa doar pe dezvoltarea de aplicatii. Nu vreau sa comentez asta pentru ca poate fi privita din mai multe unghiuri, insa desi se face push agresiv pentru intrarea in cloud, cred ca vor mai trece cel putin 10 ani daca nu mai mult pentru ca si pe la noi si pe la altii sa se contureze mai bine lucrul asta.

Revenind la high availability, in WS12 R2 asta e realizabila cu ajutorul NLB (Network Load Balancing) si FC (Failover Clustering).
Desigur, implicat e si Hyper-V-ul, cu Share-Nothing-Live-Migration, Hyper-V Replica si Extended Replica (de la R2). Scenariile de aplicare pentru NLB sunt primul lucru care trebuie luat in considerare, adica se preteaza cel mai bine ori pentru aplicatii web sau web tier care nu se modifica practic. In spate poate fi orice ca baza de date si acolo sunt aplicate alte modalitati pentru asigurarea high availability. Microsoft (MS) insista pe comenzile PS, desi astea sunt roluri care se instaleaza rar, iar pentru mine de exemplu, ca IT PRO, nu ma deranjeaza absolut deloc sa folosesc GUI in loc sa ma chinui sa gasesc tot felul de parametrii. Desigur, pot aduce totul din full in server core si sa administrez de pe o statie de lucru obisnuita si chiar e foarte OK, prefer asta, trebuie verificat doar daca server core-ul suporta anumite roluri/feature-uri. La NLB sunt cateva lucruri legat de afinitate si port rules, adica load balancing-ul poate tine cont si de maparea unei conexiuni a unui user catre un anumit nod (din max de 32 cate suporta NLB-ul) putandu-se seta un single affinity, daca are sens.

FC (Failover CLustering) presupune o analiza mai laborioasa, fiind vorba si de scenarii mai complexe cum ar fi multi-site clustering care presupune solutii suplimentare pentru replicarea storage-ului din locatii diferite. In WS12 R2, MS a inmultit capabilitatile FC-ului. Putin planning e necesar pentru decizii legate de quorum, retelele folosite de cluster-ul care urmeaza a fi creat, storage-ul necesar (ISCSI poate fi o solutie foarte buna din mai multe puncte de vedere). Foarte interesanta si ceruta de admini e CAU – Cluster Aware Updating, care permite automatizarea procesului de aplicare a patch-urilor pentru nodurile din cluster, dar tot adminii au cerut si versiunea de server core la care mai apoi, din cate spunea MS, nu prea s-au inghesuit s-o foloseasca. La fel, putina analiza e necesara si la lucrul cu SOFS (Scale-Out File Server) care oricum e strict necesar pentru guest clustering (si aici sunt lucruri de luat in calcul). Highly available VMs, failover si failback, live/quick/storage migration/setari/ cu /fara certificate, Hyper-V Broker pentru folosirea Hyper-V replica dintr-un cluster, sunt alte aspecte care trebuie planificate/testate/configurate si monitorizate, dar e fain ca se poate monitoriza un anume serviciu din interiorul VM-ului si pe baza starii lui se pot lua decizii de failover.

In final, fiecare isi stabileste propriile limite/downtime-uri care sunt acceptabile si pentru ce tipuri de aplicatii, in functie si de posibilitati. Desi se promoveaza intens si ideea de „5nine”, totusi sunt destule cazuri in care analiza poate demonstra ca nu merita investit pentru obtinerea unui astfel de gen de disponibilitate pentru unele servicii.

Am vazut ca MS chiar specifica si in documentatii, ca, costul implementarii unei solutii trebuie sa fie mai mic decat beneficiile aduse, ca oricum in lumea de azi nu mai conteaza nimic in afara de profit si comert (din pacate). Am avut neplacuta surpriza sa constat situatii in care meritele/initiativele omului si toate lucrurile frumoase pe care le aduce / le poate aduce sunt privite ca secundare, primul lucru fiind: „da contractul, cat e contractul?” parca era si o reclama, acolo fiind vorba parca de un articol vestimentar…

Windows Server 2012 R2 – infrastructure – part 3

Mentionam RODC-urile in precedentul post, precum si tab-ul de „Password Replication Policy” care permite gestionarea parolelor stocate pe ele. Pentru simplificarea administrarii, introducerea unui grup de user-i din branch si a unuia de computer-e din acel branch, in grupul de „Allowed RODC password replication” e suficient. Replicarea cu DC-urile writable poate fi configurata din AD Sites and Services si in cazul in care dorim sa grabim procesul de replicare, putem merge in site-ul dorit si aplicam un „Replicate now” pe conexiunea de replicare dorita. Desi cred ca se poate scadea replicarea automata si sub cele 15 min (printr-un mic hack daca i-am putea spune astfel), totusi nu prea ar avea sens, adica user-ii vizati deja isi stocheaza parolele pe RODC si nu sunt interesati de altele. In fine, daca asta s-ar dori sau daca se modifica politici mult prea des (desi nu e un best practice asta), se poate face, adica replicarea intersite, sa fie setata si sub cele 15 minute (daca nu ma insel) cat e limita de jos permisa.

Monitorizarea replicarii se face dintr-un tool ca SCOM sau cu tool-uri in linie de comanda ca „repadmin”, „nltest„. Cand mai primesc alerte prin SCOM, folosesc in special „repadmin /replsummary” care arata un sumar al replicarilor, erorile aparute. Poate interesa si „repadmin /queue„, care indica ce se afla in coada, asteptand replicarea. In orice caz, desi Microsoft ofera tool-uri built-in pentru monitorizare,administrare AD, backup si altele, totusi tool-urile profesionale dedicate oferite chiar de ei in pachetul System Center sau de altii sunt de preferat. Orice noua versiune de OS aduce cu sine in documentatia oferita si o sectiune de upgrade – firesc, evident. Feeling-ul pe care il am e ca lucrurile stau tot mai bine din mai multe puncte de vedere incepand cu Windows Server 2012. Probabil, asa cum a fost Windows Server 2003 si versiunea de 2012 si R2-ul ei, vor sta multi ani, drept un punct de referinta in administrare.

Ce nu-mi place e sa stau si sa folosesc tool-uri ca „dfrsmig” (pentru migrarea de SYSVOL) sau „adprep” sau sa fac tot felul de configurari inainte de a incepe setup-ul propriu-zis de SCOM sau SCCM. As prefer ca setup-ul odata lansat, sa imi ofere totul: link-uri, recomandari, fara sa mai stau sa fac in prealabil decat o actualizare la zi a OS-ului de pe server-ul pe care lucrez. Probabil si aici MS poate adduce imbunatatiri. O chestie care mi-a dat multa bataie de cap o vreme a fost instalarea WSUS-ului dupa ce am instalat initial RODC-ul. De ce MS nu avertizeaza ca Windows Internal Database a WSUS-ului (in cazul in care pentru asta optam si nu pentru SQL) nu se poate instala decat inainte de RODC? Adica rolul de WSUS sta acolo in Server Manager ca si celelalte asteptand sa dai click si sa lansezi wizard-ul care ar trebui sa mearga lin sau cel putin la asta te gandesti si asta iti doresti. In fine astea sunt aspect pe care MS ar trebui sa le imbunatateasca.

Windows Server 2012 R2 – Infrastructure – part 2

Mentionam in precedentul post de forest-uri/domenii, precum si de fuziuni. Aici au sens trust-urile
la nivel de forest/realm. Pentru simplificarea administrarii, cu forest wide authentication (selective authentication complica lucrurile, desi in practica, ea ar trebui folosita) urmat de validarea trust-ului, practic avem un trust functional si din momentul asta, putem selecta grupuri/user-i carora sa le dam permisiuni dintr-un forest in altul. Nu prea e deloc recomandat sa se creeze o structura stufoasa cu mai multe child domains/disjoined names, pentru ca pe langa complicatiile in administrare, te obliga la investitii serioase: pentru fiecare domeniu, trebuie sa avem cel putin 2 DC-uri pentru redundanta. Dar daca totusi cineva se incumeta sa faca asta, poate avea sens pentru imbunatatirea timpului de autentificare sa se creeze shortcut-trust-uri. External, ar avea sens intr-o fuziune cu o companie cu multiple domenii, dar, din nou, lucrul la nivel de trust e destul de rar. Am vazut recomandari sa nu se puna pe disable filtrarea SID –urilor, desi si asta e un caz rar. Adica inteleg totusi ca e vorba de o potentiala vulnerabilitate, dar ca sa exploatezi o chestie atat de rarisima ca un SID similar in alt forest, iti trebuie si sa fii conectat cumva la schimbarile introduse de trust-ul dintre companii si niste cunostinte foarte bune ale unor tool-uri, precum si permisiuni. Interesant de aflat daca s-a facut vreodata o chestie din asta sau a ramas doar la nivelul de vulnerabilitate potentiala semnalata.

In situatia in care avem branch-uri, vom crea site-uri, apoi subnet-uri, apoi site link-uri pe care le vom configura dupa necesitati. In ziua de azi, link-urile sunt foarte bune si nu prea e necesar sa umblam la setarile de „cost”, care oricum vor aduce modificari care vor trebui bine investigate, in acest caz. In site-uri, urmand recomandarile MS, vom plasa RODC-uri, in cazul in care branch-ul nu e prea sigur si aici, o foarte buna treaba fac optiunile de replicare de parole care permit selectarea grupurilor/user-ilor ale caror parole le dorim stocate pe RODC. Ideea ar fi ca daca cineva ar fura fizic RODC-ul, ar putea rula software pentru obtinerea de parole si daca acolo ar fi stocat de ex, vreun cont de domain admin, lucrurile pot deveni potential periculoase. Dar si in cazul asta, persoana care ar face asta, ar trebui totusi sa aiba „cojones” (daca am inteles bine asa se numesc) ca sa fure RODC-ul, sa obtina o parola, sa reintre in retea si sa incerce sa compromita serviciile pe care si le doreste. Iar, cred ca astea sunt mai degraba potentiale vulnerabilitati. Teoretic si RODC-ul ala, ar trebui tinut totusi sub o monitorizare, intr-o incapere cu acces securizat. In fine. Sunt posibile, de ex, scenarii in care nu exista nici in un DC intr-un site si un site vecin va prelua solicitarile de autentificare ale user-ilor de acolo. Cateva setari prin DNS pe la priority pentru SRV-urile de LDAP, pot directiona user-ii catre un anumit DC pentru autentificare.

Dupa site-uri urmeaza replicarea, componenta activa a infrastructurii AD.

Windows Server 2012 R2 – Infrastructure – part 1

Desi intra in categoria unor task-uri administrative care se fac foarte rar, am luat in considerare cateva posturi despre infrastructura in ultima (pana in acest moment) versiune de Windows Server. Voi incepe cu creierul retelei – AD-ul, cu a lui infrastructura. Am tot auzit exemple de companii care si-au creat un numar record de domenii/subdomenii/forest-uri si care ulterior si-au dat seama de eroare, corectand complicatiile inutile. Desi tehnologia permite usor extinderea, facilitatile introduse incepand cu Windows Server 2012, fac totusi nenecesara in majoritatea cazurilor, crearea de domenii suplimentare. Costurile cu nou hard/ noi licente sunt si ele un argument solid. Ar fi doar de luat in calcul cateva motivatii din prezent pentru acest gen de extindere:

>achizitii / fuziuni cand pentru o perioada se poate face un forest trust, se pot folosi multiple UPN’s ; chiar si in cazul asta, am vazut companii care desi fac trust, nu opteaza pentru o migrare completa catre un forest, desi 1 forest-1 domeniu e cel mai bun si mai simplu mod de lucru; ceva munca suplimentara se va face la upgrade-ul catre noi versiuni de Server OS si AD, totusi imi place ca ADPREP e inclus in wizard-ul de AD DS si nu e necesara rularea lui prealabila; teoretic, e simplu: aduci noul OS, il faci DC, join la domeniu si prin replicare si apoi migrare de FSMO, creezi terenul pentru eliminarea vechilor DC-uri; desigur si ridicarea la noul forest functional level, desi, in cazul WS12 si R2, nu e nimic in plus fata de forest level-ul din WS08 R2;

>forest-uri de test/deployment: izolarea e mult mai buna fata de izolarea oferita de un alt domeniu; foarte util pentru mediu de test; se poate crea un domeniu similar cu singurul scop de a face trial restores; desigur aici nu se are in vedere nici un fel de trust cu domeniul de productie efectiva; este cu sens si, in mod evident solicita hard suplimentar, de preferinta similar cu cel din productie; asta e necesar pentru restaurari de AD, teste de failover clustering, testare update-uri, noi versiuni de OS sau aplicatii, aspecte de securitate si alte scenarii;

>inca de la primele versiuni de Windows Server, Microsoft recomanda foarte multa atentie la lucrul cu Schema; cei care totusi au vrut sa implementeze modificari, pot lua in calcul in unele situatii si forest-uri separate, pentru ca Schema este share-uita de domeniile din forest si ca atare daca exista incompatibilitati, e necesar un nou forest;

>am vazut in documentatii foarte multe referiri la compliance cu diverse legi/cerinte guvernamentale; pentru multinationale, ca sa le satisfaca mai bine, are sens si pot implementa domenii separate pentru filiale aflate in tari care au cerite speciale; nu stiu de vreo cerinta speciala a legislatiei din Romania, dar cu siguranta si la noi, se fac progrese in obtinerea certificarilor pentru anumite departamente/fluxuri de lucru; da bine la CV cand mergi la client….nu de alta…; sunt bloguri unde oameni care cunosc foarte bine domeniul, ofera recomandari.

Pe langa motivatiile folosite pentru extinderea mediului de lucru cu mai multe domenii/childs/forests, o „mica” atentie trebuie acordata serviciului de nume, care se va complica tot mai mult: stocarea zonelor, replicarea, modalitati de optimizare a rezolvarii de nume sunt aspecte imediate care vor trebui gestionate in functie de specificul environment-ului. (…si uite asa vorbim cu totii romgleza…)

Ultimul trend in infrastructura, cloud-ul, merita tot mai multa atentie. Imbunatatirile recente de optiuni si preturi oferite pentru storage-ul in cloud de Microsoft de care am aflat la o conferinta recent tinuta, fac foarte relevanta explorarea optiunilor pe care Azure le are de oferit pentru admini – backup-ul si scenariile de DR fiind doar un exemplu.

Disaster Recovery Plan – 4

Seria de posturi oferita pe acest topic „Disaster Recovery” nu se doreste a fi tocmai cel mai profesional si mai autorizat loc de inspiratie pentru cineva care nu a lucrat la implementarea unui astfel de plan. Insist insa, pe ideea de bun simt, masuri de bun simt pe care un admin responsabil ar trebui in mod natural sa le aiba in vedere. Desigur pentru cititorii cu experienta probabil, nu sunt prea multe noutati de referinta, insa datorita faptului ca in practica am intalnit admini care desi declarativ se implica, doresc implementarea unui sistem de management tot mai bun, in realitate nu aplica nici macar un set de recomandari de bun simt, preferand sa paseze la altii sau sa amane indefinit aceste lucruri, m-am gandit ca, chiar si aspecte de bun simt si destul de basic despre acest topic merita mentionate. Cine doreste standardizari poate cauta pe site-ul ISO despre acest topic, dupa keywords ca „disaster recovery” sau „business continuity” si cu siguranta va gasi niste referinte. Probabil ca si altii au mai vazut responsabili cu securitatea care au torrente pe statie sau care nu stiu prea bine unde sa gaseasca firewall-ul. Chiar daca ceea ce subliniez nu este poate cea mai buna referinta tehnica (cum mentionam deja), exista inclusiv rapoarte recunoscute international legat de atitudinea precara pe care multe firme o au fata de securitatea datelor si backup-ul lor. Ca si concluzie la aceasta serie al carui topic ma intereseaza tot mai mult in ultima vreme (topic la care s-ar putea sa mai revin), exact cum am auzit relativ recent la o conferinta de securitate – NU TREBUIE SA NE CONSUMAM IN IMAGINAREA UNOR SCENARII APOCALIPTICE, ci pur si simplu, adunandu-ne mai multi la o masa cu un whiteboard sau un spatiu de lucru colaborativ sau doar cu niste agende, sa discutam si sa putem estima ce vrem sa protejam, cum trebuie sa fie restaurarea (cat de rapida), sa stabilim niste proceduri concrete de lucru in cazul unor situatii problematice si cum putem implementa aceste masuri, ce costuri asociate sunt si sa implicam si pe cei din zona de management de top, apoi pe cei de la financiar pentru a obtine confirmarea ca se pot pune in practica planurile/procedurile identificate/create. Spor la Disaster Recovery Plan-uri de success !

Disaster Recovery Plan – 3

In acest post vizez punctul 2 dintr-un PRSD: mod / proceduri de reactie in situatii problematice. 

Pentru IT scopul este (nu neaparat atingerea celor „five nine’s” uptime)  cat disponibilitatea serviciilor oferite in limite rezonabil acceptate si multumitoare pentru utilizatori / clienti / colaboratori. La urma urmei, nu e tocmai ieftin sa-ti faci nu stiu cate redundante cand router-ele depasesc mii de euro, iar storage-ul centralizat (desi s-au facut pasi vizibili) nici el nu e tocmai ieftin. Probabil  asta e unul din motivele pentru care se tot bate toba pe pasarea responsabilitatii functionalitatii hardware catre un provider de servicii cloud, care isi poate lua angajamentul pentru oferirea unor SLA-uri multumitoare. Plus de asta sunt destule rapoarte care indica faptul ca folosirea anumitor tehnologii de virtualizare implica costuri de cateva ori mai mari decat ale competitorilor.  SSD-urile inca mai au un drum de parcurs pana la o accesibilitate mai buna. Ideea pe care vreau sa o transmit prin acest post nu este neaparat cum sa se restaureze AD-ul sau alte tehnologii – pentru astfel de detalii tehnice sunt disponibile o multime de resurse online – ci doar faptul ca simpla respectare a unor proceduri de lucru stabilite prin MOF sau alte metodologii si a unor best practice-uri pot ajuta enorm. La o recenta conferinta despre securitatea IT s-a accentuat de mai multe ori ideea ca nu trebuie sa ne consumam pe imaginarea unor scenarii haotice despre atacuri informatice si nu trebuie sa ne inraim nici pe noi si nici colegii de la lucru, creaind un climat de continuu stress si o fluctuatie incredibila de personal (sunt cazuri reale pe care le-am intalnit, in care un om angajat azi pleaca in maxim 2 luni la o firma la care securitatea se trateaza „serios” – fara comentarii) ci trebuie pur si simplu sa incepem prin respectarea recomandarilor hard si soft ale furnizorilor de echipamente si de licente soft cu care colaboram, prin respectarea unor best practice-uri. Am avut ocazia sa discut cu un MVP care zambea cand s-a discutat despre topicul amenintarilor informatice si ne-a spus ca el nu are nici o problema si nu isi face nici un fel de griji pentru  afacerea lui, doar urmand recomandari facute de Microsoft, CISCO sau alti furnizori de servicii/echipamente in ce priveste securitatea. Un alt aspect pe care il consider relevant (tocmai pentru ca l-am vazut ignorat) este dedicarea, gradul de implicare al personalului IT in bunul mers al lucrurilor si asta se exprima prin trial-restore-uri, lucrul pe medii de test separate fizic sau logic de mediul de productie. Cu semnificatie mi se pare folosirea unui jurnal al administratorului de retea (despre care am si publicat un articol http://www.wikihow.com/Create-a-Network-Administrator-Journal) sau daca nu se doreste un astfel de mod de lucru, atunci se pot folosi diverse tool-uri colaborative pe care sa existente o modalitate de a urmari modificari/task-uri cum ar fi: portaluri interne, Yammer, file servere cu foldere restrictionate cu documentatii/baze de date sau altele. Un sistem de informare centralizat despre erori aparute pe servere sau la aplicatii critice, inclusiv avertizari prin SMS, modalitati de conectare remote in maniera securizata, posibilitatea urmaririi remote a unor parametrii fizici din datacenter sunt alte cateva lucruri/proceduri de lucru cu sens in a fi implementate. Desigur, proceduri de lucru inclusiv scrise, documentatii trebuie facute diferential, adica pe masura ce apar modificari noi, nu amanate „pentru altadata”. Este un task in plus intr-adevar, dar e unul care are sens. Pentru unele firme are sens crearea unor locatii offsite cu un sistem de replicare si capabilitati de restaurare testate.

Foarte important este insa si costul: tot ce inseamna backup/recovery/locatii offsite / high availability (hard sau soft) / redundanta pentru diverse echipamente sunt lucruri cam scumpe. De asta are sens identificarea unor situatii reale problematice si modalitati de restaurare rapida. Un alt lucru pe care l-am vazut ignorat este faptul ca unii admini/manageri IT nu se asigura ca cei cu care lucreaza inteleg bine ce au de facut si in general si in ceea ce priveste acest aspect de business continuity avut in vedere in aceasta suita de posturi. Probabil ca, considera ca e de la sine ca omul de langa tine sa vada lucrurile in acelasi mod in care le vezi si tu, insa eu unul am avut ocazia sa vad in practica tocmai faptul ca lucrurile nu prea stau cam asa.

In acest post  nu mi-am propus sa insist pe pasii efectiv de urmat daca o tehnologie sau alta are erori / probleme, pentru asta sunt destule resurse si library-uri online, ci mi-am propus sa insist mai mult pe atitudinea fata de acest proces necesar de „disaster recovery” pentru asigurarea unui „business continuity”. La urma urmei, cum spuneam si anterior multe probleme si situatii neplacute pot fi prevenite intr-un mod absolut banal si anume respectarea unor recomandari si best practice-uri.

In postul urmator voi atinge al 3-lea pas necesar intr-un PRSD si anume partea de actualizare/feedback de pe urma unor incidente.

Disaster Recovery Plan – 2

In postul anterior rezumam 3 pasi elementari in realizarea unui PRSD (Plan de Restaurare a Serviciilor si Datelor) sau un disaster recovery plan. Insa pana a face o lista a potentialelor probleme care pot aparea si a consecintelor acestora, mai intai, cerinta elementara, trebuie stiut exact ce anume merita/nu merita protejat/restaurat. Ma refer la datele cu adevarat relevante.

Putem enumera cateva:

– serviciul de directory (indiferent pe ce platforma e implementat) cu bazele lui de date;

– mail-urile;

– documente/inregistrari financiar-contabile;

– bazele de date;

– serviciile de management/monitorizare;

– website-urile care promoveaza afacerea/obiectul de activitate;

Pe langa date, mai sunt de evaluat echipamentele de retea/server-ele/storage-ul fara de care nu se poate desfasura activitatea:

– exista ruter-e/switch-uri/firewall-uri/appliance-uri/conexiuni redundante ?

– solutii de power redundate ?

– storage redundant ?

– host-urile de virtualizare in clustere;

– locatii offsite disponibile ?

Stiind ce vrem exact sa protejam, precum si locatia acestor date care, de preferinta ar trebui sa se gaseasca in cat mai putine locuri, de pilda pe anumite servere si nu pe statiile user-ilor, care nu se prea preteaza pentru backup, avem punctul de pornire.

In acest moment, ne putem gandi la primul pas mentionat in postul anterior si anume ce probleme ar putea aparea (si care ar afecta datele/serviciile/locatiile mentionate anterior si care ne sunt indispensabile in desfasurarea activitatii) si in ce mod acele situatii neplacute influenteaza datele / serviciile esentiale.

Cam cu ce tipuri de probleme ne putem confrunta?

– calamitati naturale sau situatii care pot aparea ca urmare a proximitatii unor lacuri/forme de relief/etc;

– atacuri malitioase interne/externe, intentionate/neintentionate;

– erori de configurare / acces prea permisiv si prea extins pentru prea multi admini/suprapuneri conflictuale de task-uri-setari-configurari efectuate;

– probleme cu furnizarea de energie electrica/ cu climatizarea;

– erori hardware;

– erori de OS / patch-uri;

– erori de contactare a agentilor de monitorizare/administrare de pe statii si de returnare a informatiilor relevante despre respectivul device;

– bottleneck-uri, numar de accesari / conectari  subdimensionat/anticipat incorect;

– servicii care se pot bloca, consumand resurse prea mari (CPU, RAM) si tinand HDD-ul ocupat prea mult timp, impiedicand alte cereri legitime de I/O sa astepte;

Desigur, lista de mai sus poate fi extinsa. Fiecare element din lista va aduce propriile lui complicatii/ramificatii:

1. Calamitati naturale/conflicte sociale:

Probabil ocupa un loc de frunte. Multumita mass-media, care nu rateaza nici una din nenorocirile de pe plan intern/extern, putem vedea oricand oameni care isi pun mainile in cap vazand ca li s-au distrus locurile de munca/afacerile/depozitele/fabricile/fermele.In aceste situatii, singura solutie de restaurare a datelor serviciilor nu poate fi decat o locatie offsite mentinuta din timp. Desigur, intretinuta cu ceva bani, pentru ca echipamentele/backup-urile de rezerva, nu sunt tocmai ieftine…

2. Atacurile malitioase

Am auzit de multe ori spunandu-se si pe la conferinte de profil si din partea unor specialisti ca cea mai buna aparare e implementarea baseline-ului de securitate recomandat de vendori pentru produsele lor hard/soft si crearea de awareness pentru utilizatori.

3. Erori de configurare

Din experienta, pot spune ca un mediu de testare in care sa existe o retea virtuala, in care sa se emuleze tot ce e relevant din retea si in care sa se testeze orice setare inainte de deployment, e cea mai profesionala solutie pentru prevenirea acestor tipuri de erori.

4. Probleme cu furnizare de energie, climatizarea

Se bate moneda serios pe ideea de cloud, de pasare catre un provider de cloud a raspunderilor pentru datacenter si tot ce are legatura cu el, iar clientul trebuie doar sa-si plateasca lunar o suma si sa se ocupe de administrarea serverelor sale.

5. Erori hardware

Un topic de raspundere pentru admini de care am vorbit si intr-un post publicat in alta parte si anume „Jurnalul administratorului de retea” este si mentinerea unei evidente cu echipamentele si perioadele lor de garantie. Vendorii ofera de obicei soft specializat care permite monitorizarea/diagnosticarea respectivelor echipamente, asa ca din timp se pot observa trend-uri problematice. High-availability este un alt raspuns, obtinut prin diverse tehnologii.

6. Erori de OS/patch-uri

Am constatat si eu si altii cu placere, disparitia practic, din viata de zi cu zi a celebrului (candva) BSOD – Blue Screen of Death. Minunat ! insa tot ramane necesitatea testarii separate, macar a service pack-urilor, daca nu si a altora, inainte de deployment.

7. Erori de contactare a agentilor de pe statii…

Am observat un fapt interesant: pentru retele de cateva mii de statii in sus, warning-urile primite prin SCOM, SCCM sau alte soft-uri care au agenti tinde sa se mareasca, iar timpul necesar a fi investit pentru troubleshooting creste, ocupand unei persoane tot mai mult. Ce anume este interesant? Pai interesant e ca unii factori de decizie, dupa cum am vazut, nu constientizeaza acest necesar de efort de munca. Ii ceri omului sa stie „n” tehnologii, cand de fapt ca sa poti avea rapoarte „curate” din retea, practic niste oameni trebuie sa munceasca uneori full time numai cu aceste aplicatii de monitorizare/administrare, nemaiavand timp pentru altceva, dupa cum li se pretinde. Cum era aia cu negrii pe plantatie…?!

8. Bottleneck-uri…

Se pare ca s-a constatat in destule locuri ca desi s-au investit sume imense pentru implementarea de soft/tehnologii hard, ele nu sunt folosite decat minimal in multe situatii. Daca nu monitorizeaza nimeni traficul sau daca nu ai o solutie eficienta care sa extraga esentialul din numarul mare de evenimente de trafic care pot aparea (cum am vazut ca are si ofera HP) nu e cazul sa ne mire ca nu s-a anticipat corect numarul de clienti, accesari si nu s-au prevazaut masurile corespunzatoare impotriva atacurilor de tip DoS, DDoS.

9. Servicii cu probleme…

Desi adminii spuneau de ani de zile sus si tare ca ei vor interfata minimala ca la anumite tipuri de Linux, de la lansarea versiunilor Server Core incepand cu Windows Server 2008, se pare ca lumea nu s-a prea inghesuit sa foloseasca linia de comanda, in ciuda declaratiilor. Powershell-ul e promovat agresiv as zice, dar se pare ca, cu exceptia unor situatii in care nu se poate altfel, lumea se multumeste cu GUI, iar suprafata de atac redusa prin eliminarea multor servicii in varianta server core, e totusi in continuare, un topic care da bine in prezentari si discutii, nu si in practica.

Cum spuneam lista de probleme si modul lor de manifestare e si poate deveni mult mai mare. Am enumerat doar cateva, cu cateva perspective alaturate.

Am acoperit in acest post, primul punct din PRSD (Plan de Restaurare a Serviciilor si Datelor): potentiale surse de probleme si modul de manifestare a lor.