Srđan Katić NADOGRADNJA HARDVERA I REKONFIGURACIJA POSTOJEĆIH REŠENJA

Informatički sistem kao dinamička struktura zahteva od nas da uvek budemo spremni da ponudimo neko novo rešenje kao odgovor na promene u poslovanju ili standardima. Iz tog razloga često postoji potreba da se postojeće rešenje rekonfiguriše ili da se hardverski i softverski nadogradi. Proces rekonfiguracije rešenja i nadogradnje hardvera je veoma sličan implementaciji s tim što nemamo toliku slobodu pri planiranju jer zavisimo od postojeće strukture i rešenja koje nudi najbezbolnije prelazak na novi sistem. Pre svega, u ovom članku ćemo učiniti osvrt na rekonfiguraciju hardverskih rešenja i nadogradnju hardvera, na plan koji može da bude primenjen na deo sistema (parcijalna nadogradnja ili rekonfiguracija) ili na ceo informatički sistem (generalna nadogradnja ili rekonfiguracija).
Parcijalna rekonfiguracija ili nadogradnja hardvera podrazumeva određeni segment mreže. Potreba za ovakvom intervencijom nastaje kao posledica promena zahteva za izgledom tog segmenta ili kao posledica potrebe da se taj segment prilagodi novonastaloj situaciji u preduzeću. Parcijalna rekonfiguracija je proces koji zadaje mnogo veće muke od generalne jer pored znanja koje nam je potrebno da postignemo rešenje moramo da vodimo računa o svakom mogućem uticaju ove intervencije na segmente mreže gde su u produkciji ostala stara rešenja. Isto tako moramo da se trudimo da tokom implementacije ne ugrozimo ostatak mreže. Najveća briga koju možemo da imamo je nekompatibilnost novog rešenja sa starim. Na primer, ako nadogradimo firmware na mrežnoj komponenti rizikujemo da ta komponenta više neće hteti da radi sa ostalim komponentama. Zato je potrebno da se prvo dobro obavestimo o posledicama promena koje želimo da sprovedemo. Ključne stavke su: planiranje željenog rešenja, usklađivanje sa postojećim okruženjem pri planiranju, rollback-snapshot, implementacija, testiranje.

Planiranje

Planiranje željenog rešenja je proces koji se ne odnosi samo na ovu tematiku i predstavlja celinu za sebe. Potrebno je reći da je fokus planiranja da bude u skladu sa zahtevima koji su uzrok nadogradnje ili rekonfiguracije.
Planiranje takođe mora da obuhvati problematiku kompatibilnosti novih rešenja i novog hardvera sa postojećim softverom i hardverom. Ova faza planiranja podrazumeva usklađivanje sa postojećim stanjem u mreži a u cilju postizanja pune operativnosti novonastalog okruženja i naravno, postizanja cilja koji je osnovni razlog zašto smo se odlučili da nešto promenimo u našoj mreži. Ne bi smo ništa uradili ako bi implementacijom novog rešenja narušili operativnost cele mreže ali isto tako bi ceo naš plan bio besmislen ako bi se tokom faze usklađivanja izgubile funkcionalnosti zbog kojih smo započeli izmene na informatičkom sistemu. To bi bilo kao kada bi smo hteli brži računar i dodamo 256mb RAM memorije a postojeću ploču zamenimo sa mnogo puta lošijom i sporijom jer memorija koju želimo da ugradimo radi samo sa sporijim modelom ploče. Na kraju bi smo verovatno došli do istih performansi ili bi čak naš računar postao primetno sporiji. Iz tog razloga je bitno da ne ugrozimo naš cilj tokom faze prilagođavanja rešenja.
Mnogo je češća situacija da projektant planiranjem ugrozi operativnost mreže ili npr. nekog servera. Naravno, ovi problemi se manifestuju tokom implementacije pa se često i nažalost tek tada i otkriju. U ovom slučaju, razlika u verzijama firmware-a na komponentama je u 80% slučajeva uzrok problema, pogotovo ako se radi o komunikacionoj opremi ili brand-name serverima. U ostalih 20% slučajeva radi se o klasičnoj nekompatibilnosti ili nekom drugom problemu. Iz tog razloga je skoro neophodno da planiranje nadogradnje mreže bude izvedeno u saradnji sa stručnjakom koji je rukovodio dotadašnjim instalacijama i rekonfiguracijama informatičkog rešenja koje želimo da menjamo.
Problem ne mora da bude samo gubitak operativnosti već može da bude i gubitak performansi. Na primer, dodavanjem novog switch–a u mrežu i rekabliranjem utp konekcija da koriste novi switch može da se stvori nebalansiran saobraćaj na komunikacionoj opremi, da neki switch–evi postanu uska grla i da se sveukupno obore performanse i protok saobraćaja.

Snapshot & Rollback

Snapshot & Rollback (snimanje za povratak na staro stanje) procedura nam omogućava da se u slučaju greške pri impelentaciji vratimo na početno stanje dok ne nađemo bolje rešenje. Pre svega, da bi smo mogli da se vratimo na početno stanje moramo da imamo jasnu predstavu o tome kako je pre promena tačno izgledao deo mreže koji smo krenuli da menjamo i šta smo to promenili do pojave problema. Zato je bitno da pre nego se upustimo u implementaciju uradimo snapshot sistema pomoću neke capture aplikacije ili jednostavno izlistamo i odštampamo konfiguraciju komponente na kojoj intervenišemo. Ako se radi o segmentu mreže ili izmeni topologije onda bi bilo dobro da napravimo skicu postojećeg izgleda mreže i za svaku komponentu unutar segmenta napravimo mini dokumentaciju koja bi nam pomogla da okvirno definišemo početno stanje informatičkog sistema. Sledeći korak je da vodimo evidenciju o svakoj izmeni koju smo načinili tokom implementacije kako bi u slučaju gubitka operativnosti celog sistema lako pronašli izmene koje su dovele do pada sistema. Ako se držimo ova dva pravila male su šanse da nećemo moći da se"iščupamo" iz problema koji smo napravili. To možemo da shvatimo kao Ivicu i Maricu koji bacaju mrvice od hleba za sobom dok se udaljavaju od kuće. Samo je bitno da držimo podalje "golubove" koji bi mogli da nam pojedu mrvice ili samoinicijativno urade nešto na sistemu što nije ubeleženo ili bar uočeno od strane vođe radova.

Implementacija i testiranje

Implementacija i testiranje se odvijaju unakrasno. Dobro bi bilo da nakon svakog većeg koraka testiramo učinjeno i zabeležimo rezultate. Ovo će nam omogućiti bržu i jednostavniju rollback proceduru u slučaju kasnijih problema.
Nekoliko dana nakon finalnog testiranja potrebno je obaviti consulting sa korisnicima i pitati ih da li osećaju promene u protoku podataka ili možda imaju neke primedbe na rad mrežnih aplikacija i transfer podataka. Ovo nam je uglavnom najveći reper za merenje uspešnosti rešenja jer ako je korisnik zadovoljan onda je posao zaista obavljen.
U slučaju generalne nadogradnje informatičkog sistema, kada menjamo ili nadograđujemo sve mrežne komponente ili sve serverske računare, situacija je nešto drugačija. Posao je mnogo obimniji ali je logistika planiranja jednostavnija i sama implementacija je olakšana. Ako nadograđujemo sve switch–eve na isti nivo i u isto vreme ne moramo da brinemo o nekompatibilnosti jer je sva oprema identična. Sa druge strane, tokom generalne nadogradnje mreža uglavnom ni ne može da se koristi tako da ako izazovemo pad mreže tokom implementacije ne moramo da mnogo brinemo jer nije u produkciji.

Zaključak

U prethodnim redovima je učinjen pokušaj da se ukratko opiše valjan pristup pri rekonfiguraciji i nadogradnji mreže. Deo ovakvog pristupa možete primeniti i na nadogradnju jednog jedinog računara, principi su univerzalni i omogućavaju vam da izvučete maksimum iz hardverskih promena, da ne napravite greške pri nadogradnji i da se lako izvučete iz problema koji je eventualno nastao pri procesu implementacije. Zato bez brige, ako se držite procedure uvek ćete moći da ispravite greške i dođete do ciljne konfiguracije.

Verzija za štampu