LTO 5 - akár 3TB adat 1 szalagon

Bár sokan a szalagos mentőegységek kihalását jósolták, kiváltva azokat a piacon egyre olcsóbban beszerezhető merevlemezes mentési megoldásokkal, korai lenne még temetni a technológiát, sőt…

Mérnők, ember lévén gyakorta járok ügyfelekhez, konzultálni informatikai rendszerük fejlesztéséről, korszerűsítéséről. Bármilyen témában történjen is a megbeszélés (legyen az szerver konszolidáció, központosított tárterület bevezetés, vagy akár „egyszerű” szoftverfrissítés a szervereken, stb.) egy dolgot minden esetben érintünk. Az pedig a mentés. Nehéz olyan informatika infrastruktúrafejlesztést kitalálni, ami valamilyen módon ne kapcsolódna a témához..

Ha pedig az Ügyfél mentési rendszere nem elég rugalmas (kapacitása nem bővíthető, sebessége nem felel meg a megnövekedett elvárásoknak) új eszköz beszerzésére van szükség. És ha új eszköz, akkor természetesen a legelső kérdés, hogy diszk alapú vagy kazettás mentőegység megvásárlását javasoljuk.

Erre a kérdésre természetesen nincs egyértelmű válasz, de az eddigi tapasztalatok alapján azt mondhatom az esetek többségében a kazettás mentőegység a befutó, a diszk alapú mentés csak átmeneti tárolót jelent a végleges kazettára való kiírás előtt..

Ennek elsődleges oka az LTO technológia gyors ütemben történő fejlődése lehet, melynek eredményeként a kapacitás hatványozott mértékben növekedett az elmúlt években, míg az írási sebesség is olyan ütemben javult, hogy szinte semmiben sem marad el egy lemezre történő írás sebességétől.

Különösen igaz ez a közelmúltban a HP által megjelent LTO 5-ös kazetta családra, amely az alábbi ismérvekkel rendelkezik..

Skálázható tárolási és mentési teljesítmény

• A HP LTO-5 Ultrium írási vagy olvasási sebessége 1 TB / óra, míg kapacitása akár a 3 TB-ot is elérheti egyetlen kazettán.

Nagy tárolási sűrűség, költséghatékony média

• A technológia fejlődésének köszönhetően a szalag simább, a mágneses részecskék kisebbek, minek következtében az adatsűrűség is megnövekedett. Így több adatot lehet rögzíteni azonos mennyiségű szalagon, mint a korábbi LTO kazettákon.

Intelligens patrontervezés

• A patronon elhelyezett memória chip gyorsabb elérési időt és a fejlettebb média-felügyelet biztosít a korábbi verziókhoz képest.

Tartós kazettatervezés

• A leegyszerűsített szalag útvonal csökkenti a kopást és a törmelék képződését, minek következményeként a kazetták élettartama is jelentősen növekszik.

Alapos és teljes körű tesztelések

• A megfelelő minőséget, így az adatok helyreállításának sikerességét a magas minőségű tesztelési eljárások (betöltés / kiadás, törésteszt és a környezeti stressz teszt) garantálják.

Korlátozott élettartam garancia

• A HP garanciát vállal, maximum 30 éves archiválási és / vagy 260 teljes mentésig bezárólag az LTO Ultrium kazetták élettartamára.

Mindezek figyelembe vételével, azt gondolom az LTO 5-ös technológia megbízható, rugalmas és költséghatékony mentési rendszert biztosít bármely cég számára, adatainak mentésére. Természetesen a kazetta csak az egyik szereplője a mentési rendszernek. Az eszköz ami a kazettákat kezeli legalább ennyire fontos. Gondoljunk, csak bele mekkora adatmennyiséget tudunk menteni egy 24 vagy 60 kazettát befogadni képes szalagos könyvtárra. De erről illetve ezekről az eszközökről majd a következő blog bejegyzésünkben…

P2000 G3 Reloaded, avagy MSA újratárazva

Tavaly nyáron, mikor megérkeztek az első MSA 2000 G3 tárolók, bocsánat, új nevükön P2000 G3 storage-ok, ünnepeltünk. Végre volt egy olyan eszközünk, mely egy dobozban tudta az FC és iSCSI kapcsolatokat kezelni. Azaz mindkét redundáns kontroller rendelkezett két FC és két iSCSI csatlakozóval, melyeket akár egyidejűleg is tudtunk használni. Nem kell mondanom, hogy örültünk neki. Ugyanis ezzel egyidejűleg rá tudtuk tenni a nagy diszksebességet igénylő és a lassabb sebességgel is beérő szervereket is egy dobozra. 

Azonban ez megmutatkozott a tároló eszköz árában is. Sok ügyfelünk pedig tiszta iSCSI megoldást szeretett volna, hiszen így megúszható a drága FC alapú csatoló kártyák és FC switchek árát. Volt ugyan a HP kínálatában tiszta iSCSI alapú megoldás az MSA 2000 G2 (már megint elrontottam P2000 G2), azonban ennek a 2x2 ethernet portja szűk keresztmetszet volt. Meg amúgy is ki akar G2-t venni, ha már van G3? Nos nem sokat kellett várnunk... 

Ösz végén szépen csendben befutott a P2000i G3, azaz a tisztán ethernet portokkal felvértezett kontrolerekkel rendelkező P2000 G3. És nem is akármilyen portokkal. Mindjárt két verziót kaptunk. Egy 2x4 1Gb/s, azaz kontrollerenként négy darab egy gigabites porttal rendelkező verziót, és egy 2x2 darab 10Gb/s-es verziót. 

Hogy melyik lett a kedvencünk? Természetesen az 1Gb/s-es kontrollerekkel felvértezett. Hogy miért? A választásnak egyértelműen anyagi okai vannak. Mennyibe is kerül egy 10Gb/s-es switch? Na ugye. Az ára ott jár valahol, ahol egy 8G/s-es SAN switchnek. Azaz nem járunk sokkal jobban ha ezt a verziót választjuk, mintha tisztán SAN-os megoldásban gondolkodnánk. A 2x4 1Gb/s-es ethernet port meg általában elég. És a 10Gb/s-es LAN kártyák sem olcsók. Ez a helyzet ugyan mostanában változni látszik, hiszen mostanában egyre több szerverben lesz alapfelszereltség a 10Gb/s-es ethernet hálózati kártya. Azonban míg a switchek ára nem kezd esni, addig mi az 1Gb/s-es ethernetes verziót javasoljuk.

Nyalánkságlista:

• Ötfajta kontroller - 6Gb SAS, FC, FC+iSCSI, iSCSI 1Gb, iSCSI 10Gb - kinek van ennél modulárisabb tárolója?
• Keverhető SAS, SATA, 2,5', 3,5' merevlemezek - kinek van ennél modulárisabb tárolója?
• Tárolókapacitás: 57,6 TB SAS és 192 TB SAS Midline és SATA Midline merevlemezekkel
• RAID szintek: 0, 1, 3, 5, 6, 10, 50
• Minden redundáns, aminek értelme van

Tud valaki jobbat?

Vélemény: DLP - komolyan ez kell?

Manapság a biztonsági szakemberek között slágertéma lett a DLP - Data Loss Prevention, azaz adatszivárgás elleni védelem. Minden informatikai biztonsági terméket gyártó cég szinte kötelezően hozza ki a DLP - akármi fantázia nevezetű termékét, melyek újabb és újabb technológiákkal próbálják elhitetni a potenciális vevőkkel, hogy ez, és pontosan ez az, amire nekik szükségük van.

Pár év ezzel a területtel való foglalkozás után én egy kicsit másképpen látom a dolgokat.

Érdemes végignézni a tavalyi és az idei ITBN előadásokat, szinte minden cég kötelezőnek érezte, hogy ebben a témában adjon elő, miközben a véleményem szerint a célpontban levő cégek erre még a legkisebb mértékben sem készültek fel. Miért is mondom ezt? A DLP megoldások mindegyike abból indul ki, hogy az azt bevezető cég pontosan tisztában van, melyek azok az adatok, amiket védeni akar. Nos pontosan itt van a kutya elásva. Sajnos a fehér hollónál is ritkább az a cég, mely tisztában van az adatvagyonával, azaz a védendő adataival. 

A legtöbb interjún, melyet ügyfelekkel folytattam, az ügyfelek meg tudják fogalmazni azt, hogy hogy is szeretnének védekezni, jól látják a védendő adatcsatornákat, azonban egyetlen dologgal nincsenek tisztában, a védendő adattal. Nincsenek tisztában azzal sem, hogy a cégükben hogy és merre folynak az adatok, valójában ki is használja őket, kinek van szükségük rá. 

Az ilyen beszélgetések során az ügyfelek szinte biztosan elbizonytalanodnak, és végső megoldásként felvetődik bennük a "monitorozzunk mindent" gondolata, ami ugye elvileg megvalósítható, csak értelme nincs. Gondoljunk csak bele, hogy egy átlagos munkaállomás és egy átlagos felhasználó naponta több ezer állomány műveletet hajt végre. Szorozzuk fel ezt mondjuk 1000 felhasználóval és 200 munkanappal, és máris láthatjuk, hogy az ilyen típusú monitorozásnak sok értelme nincs.

A DLP bevezetések bukásai is mind erre vezethetők vissza. Nincs adatvagyon leltár, vagy csak részleges. Vagy túlzottan monitoroznak mindent, vagy valamit kifelejtenek, így lesz a megoldásból "valami", amit a bevezető cég kitehet a referencia listára, csak a valóságban semmit sem ér. Egy DLP bevezetés költségének majdnem egészét az adatvagyon felmérés költségének kellene, hogy kitegye, ehelyett szoftvereket, vasakat vásárolnak a cégek.

Rendben van, de akkor mit is csináljunk, hogy csökkentsük az adatok elvesztéséből fakadó veszélyt? Nekem erre az egyértelmű válaszom, építkezzünk alulról, csökkentsük az adatokhoz való hozzáférést. Hogy tehetjük meg ezt? Véleményem szerint először tegyük meg az alapvető lépéseket:

- oktassuk felhasználóinkat. Mondjuk el nekik, miért fontos az adatok védelme, hogy tudnak tenni az adatszivárgás ellen. Mutassuk meg nekik a nyomtatóik környékén heverésző céges adatokkal zsúfolt gazdátlan papírlapokat...

- nézzük át file szervereink, adatbázisaink és egyéb adattárolóink jogosultsági rendszerét. Hány olyan felhasználói jog van kiosztva, mely teljesen felesleges...

- használjunk teljes merevlemez titkosítást. Notebookokon mindenképpen, de akár munkaállomásainkon, szervereken is. Naponta vesztünk el, vagy lopnak el tőlünk notebookokat és csak a szerencse kérdése, hogy a rajta levő, sokszor értékes adatokat ki, mire, hogy fogja felhasználni.

- titkosítsuk le a hordozható adattárolóinkat, vagy használjunk hardveresen titkosított eszközöket. Próbaképpen próbálja meg mindenki visszakérni a felhasználóinak idén kiosztott USB kulcsokat. Hány százalékukat kapnánk vissza? Talán 10? Hol van a maradék 90%? Milyen adat volt rajta? Senki sem tudja....

- használjunk könyvtár titkosítást. Azaz használjunk olyan megoldást, mellyel egyes felhasználói csoportjaink közös kulccsal, de a másik csoporttól különböző kulcsú, titkosított mappákban dolgoznak. Azaz aki véletlenül belelát más mappájába, az sem tud véletlenül, de még szándékosan sem adatszivárgást okozni.

Ha mindezeket a lépéseket megtettük, akkor kezdjünk el gondolkodni minden egyéb megoldáson. Addig felesleges pénzkidobás. 

Tavalyi év folyamán én is DLP-t prezentáltam, hiszen erre könnyen be lehetett csábítani az embereket a terembe. Idén nem álltam be a sorba Tamás barátommal, hanem megpróbáljuk bemutatni azt, hogy a felsorolt első lépések mennyire könnyűek, mennyire egyszerűen bevezethetőek, akár 30 perc alatt is :-)

Részletek itt.

P4000 avagy a HP legújabb adattárolási technológiája

Amikor 2008 őszén a HP megvásárolta a LeftHand Networks iSCSI tároló gyártót, nehéz volt elképzelni, milyen célból tette ezt. Elsőként mindenki arra gondolt, hogy a gyártó a meglevő MSA és EVA tárolóinak szoftverébe illeszti be a LeftHand technológiáját, ehelyett azonban egy külön tárolósorozatot jelentetett meg LeftHand, avagy újabban P4000 néven, mely kifejezetten az SMB szektor számára nyújt elérhető megoldást.

Miben is rejlik a P4000 titka? Alapvetően ez idáig minden tároló egy különálló egység volt, melyet szükség esetén lehetett replikálni vagy szinkronizálni egy másik - a megoldások zöménél kizárólag azonos - tároló eszközre. Ezzel lehetett biztosítani a rajta levő adatok védelmét, illetve a tároló eszközök magas rendelkezésre állását. A replikációs vagy szinkronizációs megoldás esetében az egyik tároló meghibásodásakor a másik eszközön még rendelkezésre álltak az adatok, amennyiben az azokat használó szerverek, és erőforrások képesek voltak rá, így akár leállás nélkül is folytathatták a feladatukat a másik tárolóról.

A jelenleg már második generációs LeftHand megoldás ezzel szemben más elvet követ. Alap kivitelben két identikus dobozzal indulunk, melyekkel már így is teljes redundanciát valósíthatunk meg a két doboz között, de más tároló megoldásokkal ellentétben ez a két tároló egy egységnek látszik az őt használó eszközök felé. További egységek hozzáadásával összeadódik az egységek kiszolgálási sebessége, tárolókapacitása és rendelkezésre állási szintje is az igényeknek megfelelően.

Ezek az alap dobozok teljesen standard HP Proliant szerver alkatrészekből tevődnek össze, ezért az eszköz költsége, támogatása is teljesen új szintekre tudott csökkenni a többi, nem standard alkatrészekből felépülő tároló megoldáshoz képest. Lényegében a HP Proliant DL 185 G5 szerverek bázisára épülnek, illetve standard Proliant szerverekbe való merevlemezekkel dolgoznak.

Mivel a HP a blade rendszerek legnagyobb szállítója is, ezért természetesen ezek a tárolók elérhetőek penge kivitelben is, ahol is a vezérlő rendszerek a C3000 vagy C7000 blade keretben, míg a merevlemezek a HP StorageWorks 600 MDS merevlemez tárolókban helyezkednek el. Ezzel kedveskedik a HP a blade alapú rendszerek kedvelőinek is, így egy vezérlő felületen keresztül menedzselhetőek a blade keretben levő szerverek és LeftHand tárolók is.

Ha a rendszerek alapja azonos a standard HP szerverekkel és kiegészítőkkel, akkor mégis mi teszi ilyen egyedül állóvá a megoldást? Természetesen a rajta futó speciális szoftver, a SAN/iQ. Ez a tároló vezérlő rendszer biztosítja a magas szintű rendelkezésre állást, melyet a gyártó Network RAID-nek nevez. Ezzel valósítja meg az alapban benne levő Microsoft VSS technológiával teljes körűen együttműködő pillanatfelvétel (snapshot) és távoli másolás (remote copy) funkciókat.

A vezérlő rendszer elérhető a VMware virtuális környezetekben is, így akár olyan környezetekben is alkalmazható a LeftHand megoldás, ahol nem alkalmazhatóak HP Proliant hardverek. Ilyenkor magán az ESX kiszolgálón fut a vezérlő szoftver és az ESX által biztosított tárterületet használja.

Kinek is való ez a megoldás? Nehéz erre válaszolni, mivel alapvetően minden méretű vállalati infrastruktúrában megállja a helyét. Mivel az eszközök sima LAN kapcsolaton keresztül kommunikálnak egymással, nincsen szükség SAN infrastruktúra kiépítésére, ezért a kezdeti beruházás gyorsan megvalósítható. A LAN-on kommunikáló iSCSI megoldás előnye az is, hogy a tárolók az egymástól több száz kilométerre levő telephelyeken legyenek, és még így is egy tárolóként működjenek. Alkalmazható virtualizációs kiszolgálók, Exchange rendszerek, adatbázis rendszerek és állománykiszolgálók háttértáraként. Képzeljük el, ha a felhasználóink ugyanazt az állománykiszolgálót tudják használni Budapesten és Szegeden is, és mindkét helyen a helyi hálózat sebességével tudjuk őket kiszolgálni.

Összefoglalva a HP P4000 adattárolási megoldásai korábban nem látott utat kínálnak a felhasználói igények kielégítésére. A megoldások nemcsak azzal tűnnek ki a versenytársak közül, hogy teljesen moduláris felépítésűek, és hogy a komplex, hiba- és katasztrófatűrő tárolóinfrastruktúrák kialakításához szükséges valamennyi alkotóelemet tartalmazzák, beleértve a helyi és távoli kétirányú replikációt lehetővé tevő szoftverkomponenseket is, hanem azzal is, hogy ezeket a figyelemreméltó képességeket fejlett, iSCSI alapú tárolóvirtualizációval is megfejelik.

EZ az indexen is olvasható: http://index.hu/info/2010/08/06/p4000_avagy_a_hp_legujabb_adattarolasi_technologiaja/

Nagymamabiztos laptop - kedvenc IT videóim egyike

Ha mégiscsak sikerülne a nagymamának kárt tenni benne, mi megjavítjuk, elvégre Lenovo gyári szerviz vagyunk.

Itt a nyár: Jönnek az IT-s viccek

Most kaptunk emailen egy informatikusoknak szóló viccet, kitesszük, reméljük nektek is tetszik :-)

IT Pálinkaszótár:


Mértékegységek:

0,1 l - Demo
0,25 l - Trial version
0,5 l - Personal edition
0,7 l - Professional edition
1,0 l - Network edition
1,75 l - Enterprise edition
3 l - Small business edition
5 l - Corporate edition

Házi pálinka - Home edition
Sörhöz feles - Service pack
Reggeli feles - Recovery tool
Sör - Patch
Coca-cola, Fanta, 7-up... - Trojan viruses

Hatásai:
Összevissza dumálás - cat /dev/random
Törpe nagy ollóval - Out of memory.
Kóma - Segmentation fault.
Másnapi elemzés - Backtrace.

Hatások az emberi kapcsolatokra:
Csajod, ha piásan esel neki - Access denied.
Azt se tudod, hogy ki vagy - Dependency check failed.
Ájulás - Connection lost.
Haver nem reagál - No answer.
A ropira akarsz rágyújtani - Type mismatch.
Végtelen mondókába kezdesz - Infinite loop.
A sarokban álló fikuszra vizelsz - Protocol error.
Kidobnak a kocsmából - Connection reset by peer.
Nem találsz el a villamosig: Network transport failure.
Rossz helyre mész haza: Bad gateway.
És nem tudod kellően megmagyarázni - Wrong number of arguments given.
Elfelejtik kihozni az italodat: Request timeout.

Hogy került Kuka mellé Törpapa?

Lassan eljön az idő, hogy az Aloha elköltözzön a jelenlegi helyéről egy új, szebb, tágasabb irodaházba. Ez a döntés, sok bonyolult kérdést hoz magával, amit csak a meglevő informatikai eszközpark bővítésével lehet megoldani. Mivel csak az aloha egyik fele költözik, a szerviz és a logisztika marad a régi helyen, hiszen egy emeleten elég nehéz egy alkatrész raktárt üzemeltetni. A megoldandó kérdések listája ezzel csak nő és nő.

A feladat, hogy ki kell alakítanunk egy megbízható site-to-site kapcsolatot a két telephely között. Igaz 2km-en belül maradunk egymáshoz képest, de a kapcsolati sávszélességünk töredéke lesz a mostani 2X1Gbps-hoz képest, a lassabb kapcsolat miatt a telephelyek között adat replikációt kell alkalmazni a fölösleges adatátvitel miatt. Ez telephelyenként saját adatbázis és egyéb szerver példányok telepítését igényli, aminek saját neveket is kell adni. A nevek kitalálása is egy fontos lépés lehet, hogy valamilyen szempontból rendszerezett maradjon a későbbiekben is az infrastruktúránk, ezért még a tervezésekor javasolt kitalálni, ugyan úgy, mint egy IP tartományt. Ezzel el is érkeztünk a mai kérdésünkhöz:

De mi legyen a szerverek neve?

Bármi, de mindenképp olyan néven-neveken érdemes gondolkodni, ami nem túl hosszú, nem túl bonyolult, és nem utolsó sorban ember közelibb, mint például egy alohabpnewfilesrv, vagy beauxbatons, vagy b612-3 hálózati nevű szerver.

Mivel most egy rendszerbővítésről van szó, már idáig is léteztek szerver nevek, amit mi mesefigurák neveivel, konkrétan a hét törpével azonosítottunk. Most sajnos elfogyott az összes név, a hét törpét, sőt még Királyfit és Hófehérkét is kilőttük, ezért új nevek után kellett nézni. Hogy mégse legyen nagy szakadék a figurák tulajdonságai között, valami hasonlót kerestünk a Törpékhez. Képzeljük el, hogy van egy DC amit Terminátornak, és van egy másik DC amit Pikachunak neveztünk el, még csak köszönő viszonyban sincsenek egymással, de kinek mi tetszik. Nálunk a Törpék mellé a Törpökre esett a választás, mert nekik is legalább olyan beszédes nevük van, és a számuk sem elhanyagolható, ami egy ideig megoldja az új szerver mennyiség problémáját.

Egy kis áttekintő a meglevő és új szerver kínálatból:

Királyfi, Hófehérke = DC + DNS + DHCP

Vidor = File és Print szerver

Szundi = SQL

Szende = Backup és WSUS

Tudor= Lotus Notes

Morgo = Web szerver

Kuka = ISA

Törpapa = ISA

Okoska = DC + DNS + DHCP

Törpilla = File és Print szerver

Lusti = Lotus Notes