Issuu on Google+

Felhő alapú hosting szolgáltatás IBM rendszereken

Készítette:

Pap Kornél Nagy Lajos Herczeg Norbert Csaba


Tartalom 1.

Bevezetés .............................................................................................................................................. 1

2.

Szolgáltatás típus kiválasztása .............................................................................................................. 2 2.1.

Szolgáltatások tulajdonságai a felhasználói oldalon ..................................................................... 2

2.2.

Szolgáltatások tulajdonságai szolgáltatói oldalról ........................................................................ 5

3. Szolgáltatás helyszíni/környezeti követelményei ..................................................................................... 6 3.1. Kolokációs szükségletek: .................................................................................................................... 6 3.2. Az általunk használni kívánt eszközök főbb specifikációi................................................................. 15 3. 3. Hozzáadott szolgáltatások: ............................................................................................................. 16 4.

Szolgáltatás üzemeltetése .................................................................................................................. 19

5.

Üzleti Modell ....................................................................................................................................... 20


1. Bevezetés

1. Bevezetés A csoportunk feladata az volt, hogy adatbázis és / vagy hosting szolgáltatás tervezetet készítsünk. Ennek első fázisa egy közös megbeszélés volt, mely során megállapítottuk a célunkat, illetve összegyűjtöttük azokat a potenciális információkat, melyeket ki szeretnénk vesézni. Miután ki lettek osztva a feladatok, mindenki utánajárt annak, ami a saját feladatköre alá tartozott. Ezt követően az összegyűjtött adatokból egy ismételt megbeszélés folyamán egyeztettük, hogy mi maradjon meg, illetve mit mellőzünk. Ezen folyamatok eredménye ez a dokumentum, mely külön fogja taglalni:      

Szolgáltatás típusának kérdését Szolgáltatás helyszíni/környezeti követelményei Erőforrás követelményeket Szolgáltatások bevezetési fázisát Szolgáltatások élettartama alatti szükséges és elégséges feltételeket, kötelességeket Üzleti modell tárgyalását

Elöljáróban: Mivel a téma, amit kaptunk elég flexibilis/szerteágazó területet fed le, ezért úgy gondoltuk, hogy a mai trendeknek, és gazdasági feltételeknek leginkább megfelelő témát választjuk, amely a cloud alapú VPS szolgáltatás lenne. Ennek kifejtését, illetve a tervezetet magát pedig a következő oldalak taglalják.

1


2. Szolgáltatástípus kiválasztása

2. Szolgáltatás típus kiválasztása Az első dolgunk a tervezés során az volt, hogy találjunk egy olyan szolgáltatásformát, mely még nem feltételen kiaknázott, van piaci alapja belefogni, illetve annak tekintetében, hogy nem multinacionális vállalatokhoz illő tőkével rendelkezünk, azt is számba kellett vennünk, hogy mi az, amit meg is tudnánk valósítani. Mivel az IT piac jelenleg is töretlenül a felhő alapú szolgáltatások felé halad annak lehengerlő előnyei miatt, ezért úgy gondoltuk, hogy mi is ezen a vonalon indulunk, mivel így a bekerülési költség minimalizálható, és nem csak az ügyfelek kapnak skálázható szolgáltatást, hanem mi magunk is az igényeknek megfelelően tudunk bővülni. Miután a szolgáltatás technikai része kiválasztásra került, következett a szolgáltatásnak magának a kiválasztása. Adatbázis, illetve hosting szolgáltatás témakörben nagyon sok potenciális ellenféllel kellett volna számolnunk, akiknek már van bejáratott ügyfél köre, illetve neve is ahhoz, hogy megnehezítse a dolgunk. Ennek a tükrében és annak, hogy mennyi hátránya van egy dedikáltan vagy adatbázis, vagy web/egyéb hosting szolgáltatásnak úgy döntöttünk, hogy cloud hosting szolgáltatást fogunk üzemeltetni.

2.1.

Szolgáltatások tulajdonságai a felhasználói oldalon

Az alábbi részén a dokumentumnak részleteznénk az előnyeit, illetve hátrányait az egyes szolgáltatás típusoknak a felhasználó szemszögéből. Fontosnak tartjuk ezt a felmérést is, mivel a potenciális felhasználóink elégedettségén múlhat a saját sorsunk is. Szeretnénk kihangsúlyozni, hogy ez a felhasználók oldaláról nézve vett összehasonlítás, nem pedig a szolgáltatói oldalról!

2


2. Szolgáltatástípus kiválasztása

Cloud hosting

Web/adatbázis hosting

Alacsony induló költség skálázhatóság 99,99+ 99,5 Rendelkezésre állás Konfigurálható rendszer Telepíthető szolgáltatások Egyszerű kezelhetőség* Ügyfélszolgálat* Adatbiztonság* *: a csillagok száma maximum 5, minimum 1 db lehet, minél több, annál jobb a) Alacsony induló költség: A jelenlegi gazdasági helyzetben talán a legfontosabb szempont - bármilyen méretű cégről is legyen szó - a szolgáltatás költségei. Mindkét fenti esetben elérhető az alacsony bekerülési költség. Ami fontos tényező lehet, az az, hogy cloud hosting esetén az esetek döntő többségében havi bontásban történik a számlázás, míg web/DB hosting esetén hosszabb időszakonként kell fizetni, jellemzően fél/egy évente. Az egy évre bontott költségek lehetnek közel azonosak abban az esetben, ha a legalacsonyabb kivitelű szolgáltatást választja valaki. b) Skálázhatóság: Skálázhatóság terén már a web/DB hosting nem tud egyáltalán labdába rúgni. Nincs lehetőség sem tarifaváltásra, sem upgrade/downgrade-re. A felhő alapú szolgáltatások egyik kulcsfontosságú előnye itt mutatkozik meg. c) Rendelkezésre állás: Rendelkezésre állás tekintetében az architechtúrális és szervezési tulajdonságaik miatt elmondható, hogy egy web hosting esetén nem támaszkodnak annyira a rendelkezésre állásra, nem előfeltétele a szolgáltatásnak az, hogy olyan mértékű legyen, mint egy felhő alapú szolgáltatás esetén. Több szolgáltató/tás tanulmányozása után tudtunk erre következtetni.

3


2. Szolgáltatástípus kiválasztása

d) Konfigurálható rendszer: Web/DB hosting esetén ilyenről szó sincs, esetlegesen cron és egyéb egyszerű műveleteket leszámítva arról, hogy hozzáférhessünk a rendszerünkhöz, amin dolgozunk, viszont cloud alapú rendszereknél akár: -

Mi választhatunk OS-t Teljes (root) hozzáférésünk van a rendszerhez Úgy állítjuk be, ahogy akarjuk

e) Telepíthető szolgáltatások: Bár szoftvereket tudhatunk telepíteni web/adatbázis hosting esetén is, ezek általában kimerülnek különböző forum/blog szoftverekben, amik pl. a rendszer működését nem befolyásolják. Ez cloud hosting esetén szintén teljesen a felhasználó kezében van f) Egyszerű kezelhetőség: Pl. web hosting esetén ez mindenképpen előny, ha a felhasználó nem kíván semmivel sem szöszölni, akkor megteheti azt, hogy feltelepíti pl. a blogját, és használja. Semmi egyéb beavatkozás nem szükséges. Felhő esetén ez nem így van. Pontosan a flexibilitásának köszönhetően alapértelmezetten bonyolultabbnak tekinthető az indulás, arról nem is beszélve, hogy mivel teljesen rajtunk múlik, hogy milyen a rendszerünk, könnyen el tud bánni magával a felhasználó. g) Ügyfélszolgálat: Az ipari standardeknek köszönhetően felhő alapú szolgáltatások esetén általában elmondható, hogy az ügyfélszolgálat jobb minőségű/jobban kiépített/kezelt. Web/DB hosting esetén előfordulhat, hogy egy nap is eltelhet, míg kapcsolatba tudunk lépni a rendszerünk kezelőjével. Cloud szolgáltatásnál ekkorra delay a bejelentés és a beavatkozás között elfogadhatatlan. h) Adatbiztonság: Adataink biztonsága, helyreállíthatósága, megőrzése kulcs fontosságú tényező bárki számára. Ebben a tekintetben mind a két tárgyalt lehetőség tud jól szerepelni, mivel a felhő alapú rendszerek általában hasonló elemekből állnak, a különbség a mennyiségekben van (a felhő javára). Ezért teljesen általánosítani nem tudtunk, a felhőt favorizáljuk, de talán nem feltétlen nagy előnnyel.

4


2. Szolgáltatástípus kiválasztása

2.2.

Szolgáltatások tulajdonságai szolgáltatói oldalról

Az alábbiakban az előzőleg felsorolt szolgáltatási formákat fogjuk értékelni viszont most a saját oldalunkról. Azt próbáljuk taglalni, hogy számunkra mik voltak azok a tényezők, amik az egyik oldalára billentették a mérleget. Cloud hosting

Web/adatbázis hosting

Alacsony induló költség Skálázhatóság Kihasználhatóság Kontroll

a) Alacsony induló költség: Az alacsony induló költség fontos tényező befektető/szolgáltatói oldalról is, hiszen a vagyonunk nem végtelen, szeretnénk minél olcsóbban megúszni a dolgot. Továbbá előzetes tanulmányok alapján tudható, hogy egy szolgáltatás fenntartási, üzemeltetési költségei a húzóerő hoszszú távon az erőforrás igény esetén, és nem annak beindítása (ami egyszeri beruházási költség mindkét esetben). b) Skálázhatóság Amennyiben a szolgáltatásunk elérné a kihasználtságának végét, biztosítani akarjuk azt, hogy minél egyszerűbben, és simábban tudjuk az erőforrásainkat bővíteni. Ezt felhő alapú rendszereknél nagyon egyszerűen meg tudjuk oldani, míg egyszerű webes/adatbázis hosting esetén bonyolultabb, vagy konkrétan problémás. c) Kihasználhatóság Erőforrásainkat nem szívesen szeretnénk üresjáratban tartani, hiszen költséggel járnak, továbbá szeretnénk a lehető legkevesebb erőforrást szánni arra, hogy ellássuk a kitűzött feladatainkat. Ezt a problémát ismét a felhő alapú rendszerek kezelik a legjobban. A másik oldalról viszont szinte semmi beleszólásunk sincs abba, hogy milyen erőforrásunk mennyire kihasznált. „Odaadjuk” a felhasználónak a csomagját, amivel azt kezd, amit akar, a függő, kihasználatlan tárterület, stb… pedig „kárba vész”. d) Kontroll Saját eszközeink kiszanáltságát, terhelés elosztását, adatok mozgatását, mind - mind egyszerűbben meg tudjuk oldani amennyiben felhőben gondolkozunk. A másik esetben erre eszkö zünk nem igazán van. 5


3. Szolgáltatás helyszíni/környezeti követelményei

3. Szolgáltatás helyszíni/környezeti követelményei A követelmények alapvetően két csoportra bonthatóak: a kolokációs szükségletekre és a hozzáadott szolgáltatásokra. Mivel a feladat adatközpont tervezésre lett kiírva, így e tekintetben értelemszerűen a kolokációs szükségletek az, ami fontos, de törekedve a teljes megvalósításra, a hozzáadott szolgáltatásokat is belevettük a leírásba. A Data Center tervezésekor a Tier 4-es biztonsági fokozatú előírást követjük, vagyis a kétszeres hibatűrésű rendszer (2*N+1) feltételeit valósítjuk meg. Ebből fakadóan a 99,995 %-os rendelkezésre állás (SLA ) az alapkövetelmény, annak érdekében, hogy elkerüljük a kötbérezést. Megjegyzés: A lent taglalt megoldási javaslatokat az általam ismert ANSI TIA 942 szabvány alapján tettem meg, amit ennek a feladatnak a készítésekor még nem ismertem teljesen behatóan – Pap Kornél csapatvezető

3.1. Kolokációs szükségletek: Adatközpont tervezéskor szembe kell néznünk az általános kihívásokkal és törekednünk kell arra, hogy ezeket a lehető leghatékonyabban oldjuk fel. Ezek a kihívások a következők: a. b. c. d.

Helyszíni szükségletek (áramellátás, légkezelés , tűzvédelem, biztonság) Szerver szükségletek és szerver elhelyezési paraméterek Struktúrált kábelezési rendszerek Informatikai biztonsági rendszerek

a) Helyszíni szükségletek Mindenekelőtt szükséges egy épület, ami megfelelően fel van készítve az adatközpontunk számára. Az egyszerűség kedvéért ennek az épületnek most csak egy paraméterét vesszük alapul: kellően nagy az induláshoz és van benne helytartalék a bővítéshez. Ennek folyamán a választás egy H3 méretű (Large Data Center) adatközpontra esett. A további szempontok a következők: 1. stabil (ingadozásmentes) 50 Hz-es áram biztosítása (tiszta áram) - redundáns UPS rendszer - redundáns diesel aggregátorok

6


3. Szolgáltatás helyszíni/környezeti követelményei

2. megfelelő kábelezési rendszer, hőmérséklet és páratartalom biztosítása - megfelelő teherbírású álpadló - precíziós klíma berendezések 3. fizikai biztonság - iparbiztonsági alkalmasság (Telephely Biztonsági Tanúsítvány, extrém esetben Minősített NATO Beszállításra Alkalmas tanúsítvány)

A fent három szempont kicsit bővebben. Az áramellátás kritikus pontja az üzemeltetésnek, mivel áram nélkül nem mennek a szervereink, ami leálláshoz vezet, és ezt nem engedhetjük meg. Ennek elkerülésére két körös áramellátási rendszer kerül kiépítésre. Az első kör tartalmazza a szünetmentes tápegységeket (UPS). Kettős feladatuk van: egyrészt biztosítják a feszültségingadozás-mentes energiaellátást, másrészt áramszünet esetén biztosítják az energiát a második kör bekapcsolásáig. Itt a választás a Gamatronic 10kVA-500 kVA szünetmentes tápegységre esett.

Gamatronic 10kVA-500 kVA specifikációk: - Power+ típusú , 3/3 fázisú, szinuszos, on-line - 10 kVA-100kVA , ill. 25kVA-500 kVA teljesítménnyel, igény szerinti áthidalási idő - Moduláris felépítés, N+n redundáns- hot swap üzemmód- APC Symmetra (PSX) rendszerű - 10 kVA, ill. 25kVA-es modulokban tetszés szerint bővíthető, redundáns rendszerként működő - Meghibásodás esetén az áramellátás megszakítása nélkül cserélhető modulok - Kis helyigény - Hálózaton keresztül Web és SNMP menedzselhető. A második kör a diesel aggregátorokból áll. Ezek feladata a teljes áramellátás biztosítása a kimaradás idején. Hosszabb leállások elleni védelemként külön szerződéskötés egy diesel beszállító céggel (MOL) annak érdekében, hogy ne fogyjon el a generátorokból az üzemanyag. Itt a választásnál a fő szempont a 2.5 MVA teljesítmény és a 24 órára elegendő gázolaj tartalék. Alternatív energiaforrásként megemlítjük az üvegpiramisos energiatermelést, ami esetünkben teljesen használható, tekintve, hogy lapos tetejű épületről van szó. Az így nyert energiát, a betápra visszavezetve energiát takaríthatunk meg, elősegítve a zöld informatika koncepcióját.

7


3. Szolgáltatás helyszíni/környezeti követelményei

A klimatizálásnál a cél a 22 C-fok (+- 2 C) és a 45%-os páratartalom (+- 10%) a fenntartandó érték. Mivel Blade szervereket állítunk üzembe, így a hűtésre egy mostanában elterjedt rack szekrényes hűtési megoldást választottunk. A STULZ CyberRow terméke fizikailag akkorra, mint egy rackszekrény, így pontosan beleillik a rackszekrények soraiba. Ezzel a megoldással jelentősen javul a légelosztás, mivel a hűtés közel van a hőforráshoz és a levegőt vízszintesen tereli. A hideg levegő az oldalsó kimeneteken át kétfelé szállítódik és egyenletesen oszlik szét az adatközpontban. A rendszer közelsége a rackekhez azt eredményezi, hogy a levegőnek rövid utat kell megtennie, így csak kissé kell, keveredjen a hideg és forró levegő. Még egy előnye, hogy a szerver rackektől való teljes elkülönülés növeli a megbízhatóságot és az adatközpont kialakításához nagyobb tervezői szabadságot nyújt. Ezen felül a tetőszerkezeten biztosítani kell a szabad levegő beengedését, azért hogy amikor a környezeti időjárás megengedi a szabad levegő beáramoltatásával „átöblíthessük” a belső légteret.

A tűzvédelemnél a tűzjelző rendszer kiválasztásánál a mára elterjedt Aspirációs VESDA tűzjelző rendszerre esett a választás. Miért ez? A VESDA füstérzékelő úgy működik, hogy folyamatosan szívja be a levegőt a csőhálózatba egy magas hatásfokú szívóberendezés segítségével. A levegőminta ezután egy kétszintű szűrőn halad keresztül. Az első szintű szűrés eltávolítja a port és egyéb szennyeződéseket a mintából, ami aztán bekerül egy lézeres érzékelő kamrába, ahol a füstérzékelés zajlik. A második szintű (ultra finom) szűrés tiszta levegőt adagol a mérőkamrába, hogy az érzékelő optikai alkotóelemeit megvédje a szennyeződéstől, ezzel elősegítve a további stabil kalibrációt és az érzékelő hoszszú élettartamát. A filterből a levegőminta továbbhalad a kalibrált érzékelő kamrába, ahol egy lézerfény sugárzásának van kitéve. Ha a minta tartalmaz füstöt, a fény azon szétszóródik, amit a mérőkamra rendkívül érzékeny érzékelői érzékelnek (térhatású vizsgálat), az érzékelők jelét zseniálisan kialakított szoftveres jelfeldolgozás követi. A feldolgozás után a jel továbbítódik és megjelenik egy grafikus kijelzőn. A VESDA érzékelők aztán képesek ezt az információt egy tűzjelző központ, egy (megfelelő) szoftver, vagy egy épületmenedzsment-rendszer felé továbbítani reléken vagy RS kimeneten keresztül. A fenti leírás a gyártó oldaláról származik és tükrözi mindazt, amire szükségünk van: egy gyorsan reagáló, hatékony és menedzselhető tűzjelző rendszerre.

8


3. Szolgáltatás helyszíni/környezeti követelményei

Tűzoltásra az INERGEN oltógázos tűzoltórendszert választottuk. Azért ezt, mert teljesíti az egyik legfontosabb kritériumot: az esetlegesen bent ragadó személyeknek esélyt ad a túlélésre. Hogyan teszi ezt? Lényegében a rendszer a tűz oltáshoz az oxigén kiszorítás elvét alkalmazza, ami a megszokott kb. 21 %-os oxigéntartalmat a védett térben 10-14 %-ra csökkenti. Ez az oxigéntartalom az ember számára nem jelent semmilyen egészségkárosodást, vagy veszélyt, ezért az esetlegesen a helyiségben maradt személyek biztonságban vannak, miközben az égés feltétele (17–18 % oxigén koncentráció) megszűnik, így a keletkezett tűz kialszik.

A létesítmény fizikai védelméről csak annyit írunk itt le, hogy fontosnak tartjuk azt, hogy adatvédelmi szempontból magas besorolásúak legyünk, így a cél a Minősített NATO Beszállításra Alkalmas tanúsítvány megszerzése. (Megjegyzés: Nem vagyok tisztában a NATO auditálás folyamatával, ezért nem taglalom bővebben ezt a részt – Pap Kornél). Egyéb biztonsági megoldásokról a d) pontban lehet bővebben olvasni.

b) Szerver szükségletek, elhelyezés Szerverválasztáskor a döntés Az IBM BladeCenter HS21 XM blade szerverére esett. A választás kulcs paraméterei a következők voltak: -

Cloud hostingot valósítunk meg így alapfeltétel a magas rendelkezésre állás VPS hosting lévén egyensúlyt kell teremteni a HPC, a webes és az üzleti alkalmazás képességei között Clusterezés, virtualizáció támogatása Nagy teljesítményű adatbázis kezelés támogatása

A választott szerver ezeknek teljesen mértékben eleget tesz. A következő feladat a megfelelő storage rendszer kiválasztása. Itt a választás az IBM Storwize V3700-ra esett. Itt a választás paraméterei: -

Támogassa a virtualizációt Fibre channellen kommunikáljon Raid 10, Network Storage támogatása (NAS, SAN)

A Storwize V3700 minden kritériumnak megfelel. 10 Gbps iSCSI/Fibre Channel sebessége és ethernet porton való kommunikációja képessé teszi NAS, SAN struktúrába kötését, a menet közbeni cserélhetőség pedig biztosítja a magas rendelkezésre állás képességét.

9


3. Szolgáltatás helyszíni/környezeti követelményei

Mindkét eszköznek a további technikai paraméterei megtalálhatók az IBM weboldalán, mi a dokumentum végén összegezzük ezeket. Elhelyezésüket tekintve a rackszekrények sorokban kerülnek beállításra, így a feljebb említett klímaberendezések használatával megvalósul a soros levegőhűtés. c) Struktúrált kábelezési rendszerek Ebben a részben taglaljuk a hálózati struktúrát, valamint a szükséges hálózati eszközöket. Kábelezési oldalról szükségünk lesz:

- Mono- és multimódusú optikai (Gigabit Ethernet és 10 Gigabit Ethernet) kábelezési rendszerre, valamint

-

Réz alapú (Fast Ethernet, Gigabit Ethernet és 10 Gigabit Ethernet) vízszintes és horizontális kábelezési rendszerekre

Utóbbi kábelezési rendszert a belső hálózaton építjük ki, míg az előbbit az ISP felé történő kommunikációra használjuk. A megfelelő aggregáció miatt szegmentáljuk a belső hálózatot. A rackszekrényeken belül a kommunikációt virtual switchek biztosítják. Erre az IBM Distributed Virtual Switch 5000V megoldását választottuk. Minden rackszekrény kapcsolódik egy, csak az adott rackszekrényhez tartozó switch-hez. Ez hivatott biztosítani a szerverek egymás közti kommunikációját egy szekrényen belül. A switchek további switchekhez kapcsolódnak, ezek között történik az összenyalábolt hálózati forgalom. Erre a feladatra az IBM System Networking RackSwitch G8000 eszközét választottuk. Kielégíti a feladathoz támasztott követelményeket, melyek: -

virtualizáció támogatása redundáns elemekből épül fel (táp, hűtő, egyéb HA megoldások) alacsony fogyasztás

Mivel Fibre channel-t használó Storage megoldást alkalmazunk így szükségünk van itt optikai kábelezésre, Fibre Channel Switchekre. FC switchnek az IBM Brocade VDX 6730 Converged Switch –ét választottuk.

Az eszközök specifikációi a dokumentum végén olvashatóak.

10


3. Szolgáltatás helyszíni/környezeti követelményei

d) Informatikai biztonsági rendszerek Egy másik kulcskérdése az üzemeltetésnek a biztonság. Általános megállapítás, hogy nincsen tökéletes biztonsági rendszer, de törekedni kell arra, hogy kellő biztonságot biztosítsunk a rendszer használhatóságának megléte mellett. Adatközpont tervezéskor elsődlegesen az ott fellépő biztonsági problémáknak kell elébe menni (fizikai védelem, megfigyelő rendszer, beléptető rendszer). Ezek megfelelőségéről biztosít bennünket a Telephely Biztonsági Tanúsítvány megléte. A tanúsítványt csak a megfelelő auditálás után adják át, így ennek birtokában biztosak lehetünk benne, hogy az előbb említett biztonsági berendezések, protokollok megfelelnek a kívánalmaknak. A biztonsági kérdéseknek számos más sarokköve is van úgy, mint: a hardweres tűzfalak használata, az alapos hálózati struktúra megtervezése, az authentikáció, a behatolás detektálás és ellenőrzés, a vírusvédelem, a centralizált jogosultságkezelés, az incidenskezelés, az adatvédelem, a tartalomszűrés valamint a loggolás. Bár a feladatnak ez már nem lenne szerves része, azért igyekeztünk legalább említés szinten összeszedni ezekre manapság használt megoldásokat. Megjegyzés: az itt felsorolt megoldások a teljessége igénye nélkül kerülnek feltüntetésre, azokat sorolom fel, amiket jelenleg ismerek, és azt írom le, amit eddig tudok róluk – Pap Kornél -

Tűzfalak - Cisco ASA – HA tűzfalmegoldás, képes virtuális hálózatok kezelésére és virtuális tűzfalak futtatására - Check Point Firewall - állapottartó csomagszűrő (Stateful Packet Filter) a packet filterek gyorsaságát a proxyk (FTP, SMTP, HTTP, telnet) intelligenciájával ötvözi, ezáltal gyors és nagy biztonságú, valamint a tűzfalszolgáltatások bőséges tárházát biztosítja felhasználóinak. Nyitott architektúrája révén több száz más gyártó hardver- és szoftvereszközeivel képes együttműködni (pl. routerek, switchek, vírusirtók, behatolásfigyelők, tartalomszűrők). A rendszer alkalmas magas rendelkezésre állású, terheléselosztott környezet kialakítására. - Zorp Firewall Professional – A BalaBit terméke. Egy új megközelítése a hálózati védelemnek. A technológia a csomagszűrés és a protokollelemzés kettősét egészíti ki a részletes adatelemzéssel. Speciális eljárással a 16 leggyakrabban használt protokoll esetében képes a teljes adatfolyam értelmezésére, elemzésére és módosítására. A rendszer proxy-jai mind a tűzfal egy-egy modulját képezik, amelyek összeköthetők,

11


3. Szolgáltatás helyszíni/környezeti követelményei

így a technológia alkalmas a beágyazott protokollok (pl. HTTPS, POP3S) kezelésére, ezért biztonságot nyújt a manapság egyre népszerűbb e-business alkalmazásoknál is. -

Behatolás detektálás, ellenőrzés

-

IBM – Internet Security Systems (ISS) - Az ISS Proventia appliance megoldások szabványos hardver és szoftver platformokra épülnek. A megoldások hardvere Intel alapú rackbe szerelhető szerverek, melyek tartalmazzák a szükséges hálózati csatolókat is. Az operációs rendszer egyéni módon telepített és biztonsági kiegészítésekkel ellátott Red Hat Linux. Ezen eszközök hálózati IDS/IPS-ek, melyek képesek a hálózati forgalom analizálására, támadás esetén riasztások küldésére és szükség esetén beavatkozásra. Típustól függően "klasszikus" hálózati IDS-ként is (hálózati eszköz monitoring portjára csatlakoztatva), vagy inline IDS-ként rendszerbe illeszthetőek. Emellett a termékskála tartalmaz egy integrált hálózatvédelmi megoldást, mely egyesíti magában a tűzfal, IDS, vírusvédelem, SPAM szűrés, tartalomszűrés funkciókat. Az ISS Proventia Server teljesen automatikus realtime behatolás-detektálást, behatolás-védelmet valósít meg azáltal, hogy analizálja az eseményeket, az operációs rendszer naplóbejegyzéseit, minden befelé, kifelé irányuló forgalmat, blokkolja a gyanús tevékenységeket, mielőtt azok kárt okozhatnának. A rendszer protokoll-analízist és támadási minta összehasonlítást alkalmaz. Mivel minden forgalmat monitoroz, így képes megakadályozni ismert és ismeretlen támadásokat egyaránt. Az ISS Proventia Desktop alkalmazás egy fejlett desktop/laptop védelmi rendszer: egy teljes értékű behatolás-detektáló, behatolás-védelmi rendszer. Együttműködik számos VPN alkalmazással, így mind az irodai hálózaton található munkaállomások mind a mobil/távoli felhasználók munkaállomásainak védelmére is alkalmas. Az ISS Proventia Desktop megvédi a munkaállomásokat azáltal, hogy analizál minden tevékenységet, kontrollálja a telepített alkalmazások működését és kommunikációját anélkül, hogy a felhasználó számára kellemetlenséget okozna. A Proventia Desktop tűzfal komponense blokkolja a támadási kísérleteket. Az engedélyezett kommunikációt is analizálja a rendszer, így az engedélyezett alkalmazásokba ágyazott, nem üzemszerű működést is képes kiszűrni (pl. Spywareek által generált forgalom). Az ellenőrzés kiterjed minden egyes csomagra és kapcsolatra. A protokoll-analizáló engine dekódolja és strukturálisan analizálja a teljes hálózati kommunikációt, így a töredezett támadási csomagokat is képes kiszűrni. Amennyiben támadást érzékel, közbeavatkozik és megakadályozza annak 12


3. Szolgáltatás helyszíni/környezeti követelményei

működését. Amíg egy személyes tűzfal mindössze csak engedélyez, vagy tilt forgalom típusokat, addig a Proventia Desktop analizálja is azokat, így biztosítva a teljes szűrési funkcionalitást. -

Adatvédelem - McAfee Data Loss Prevention – Teljes körű védelmet biztosít, ellenőriz minden csatornát, amelyeken át adatok szivároghatnak el. Fizikai védelem: - USB eszköz (akár Whitelist eszközök is) - Memóriakártya - Nyomtató - Scanner - CD, DVD - floppy Hálózati védelem: - File szerver - Webmail - HTTP, FTP - Wi-Fi - Bluetooth Alkalmazásszintű védelem - Email küldés - Webes feltöltés, webes levelezés - Képernyőlopók - Peer-to-Peer hálózatok - Instant Messaging alkalmazások

-

Authentikációs rendszerek

- RSA SecurID - A rendszer a felhasználókat az általuk birtokolt hardver tokennel és a hozzá tartozó PIN kóddal azonosítja. A rendszer lelke egy központi azonosító szerver, szervercsoport (terhelésmegosztás). A tokeneken percenként változó kód jelenik meg, mely a megfelelő PIN kóddal kombinálva egyértelműen azonosítja a felhasználót. A rendszer védett lehallgatás ellen is azáltal, hogy a felhasználó azonosítója percenként változik és egy kódot csak egyszer fogad el a rendszer. Az azonosító kódot a token egy beépített mechanizmus és egy gyári SID kód alapján generálja, melyet csak az adott token "tud", illetve a központi azonosító rendszer. -

Incidenskezelő, LOG elemző rendszerek - SysLog NG - A syslog-ng PE egy multiplatform központi naplózó megoldás, amely tartalmazza a naplózó klienst és a naplózó szervert is. A naplóelemzők egyrészt auto13


3. Szolgáltatás helyszíni/környezeti követelményei

matikusan és eseti lekérésekre riportokat készítenek, melyekből a rendszert üzemeltető adminisztrátorok nyomon követhetik a rendszer általános állapotát. Ezek a statisztikák vonatkozhatnak a hálózati kapcsolat, a processzorok vagy a merevlemezek csúcs és átlagos terhelésére; bizonyos szolgáltatások igénybevételének eloszlására és még sok minden másra is. Másrészt, a logelemzők alkalmasak előre definiált események bekövetkeztét érzékelni, és az előre beállított csatornákon riasztást küldeni. Az előre definiált események tulajdonképp az üzemeltetők által beprogramozott intelligencia, mely segítségével az elemző szoftver tudja, milyen hálózati állapotok együttállása jelenthet biztonsági szempontból aggályos eseményt. A riasztások történhetnek konkrét értékek figyelésével, de a kifinomultabb, öntanuló rendszerek képesek a tőzsdei grafikonok elemzéséhez hasonlóan akkor is riasztani, ha bizonyos időbeli diagrammok formája a normálistól eltér. Az időszakosan generált riportok segítségével a hálózat üzemeltetői könnyedén kielégíthetik a különböző auditok által megkövetelt dokumentációt. -

-

Cisco MARS - A Cisco Security MARS a veszélyforrások kezelésére, megfigyelésére és elhárítására használt nagy teljesítményű, jól méretezhető készülékcsalád, amelynek segítségével az ügyfelek hatékonyabban kihasználhatják hálózati és a biztonsági eszközeiket. A biztonsági események hagyományos figyelését és az automatikus elhárító funkciókkal rendelkező hálózati intelligenciát egyesíti. - Kiszűri a számos különböző hálózati összetevőn (Cisco és más gyártmányú termékeken) áthaladó adatokat, megkeresi köztük az összefüggéseket, majd elhárítja az esetleges támadásokat - Képes megállítani a folyamatban lévő támadásokat, és felfedni a támadás útvonalát - A dedikált készülék egyszerűen és gyorsan üzembe helyezhető - Kiváló teljesítmény: másodpercenként akár 10 000 eseményt is képes kezelni A Cisco Security MARS a Cisco Security Management Suite biztonságfelügyeleti csomag része, amely a Cisco önvédő hálózat biztonsági szabályainak adminisztrációját és átfogó érvényesítését teszi lehetővé.

Vírusvédelem: - Trend Micro alapú vírusvédelmi megoldások – Csomagban kézhez kapott, elsősorban nagyvállalati vírusvédelmi megoldások. A csomag összetevői: - Trend Micro ServerProtect: A Trend Micro ServerProtect a Windows NT/2000/2003 vagy Novell NetWare operációs rendszerű kiszolgálók számára kínál megbízható vírusvédelmi megoldást. - Trend Micro OfficeScan: A Trend Micro OfficeScan Corporate Edition változata egy teljes nagyvállalati desktop vírusvédelmi megoldás. Könnyen telepíthető szerver oldalról, automatikusan frissíti a vírusadatbázisokat és magát a szoftvert, valamint jelentéseit központilag készíti. - Trend Micro ScanMail: Napjainkban a vírusok túlnyomó többsége e-mailen 14


3. Szolgáltatás helyszíni/környezeti követelményei

keresztül terjed. A Trend Micro a levelezőszerverrel szorosan együttműködő megoldást k��nál a Lotus Notes, a Microsoft Exchange illetve az OpenMail használóinak. - Trend Micro InterScan Messaging Security Suite: Az InterScan Messaging Security Suite SMTP és POP3 protokollon végez vírusszűrést, így a hálózat határán blokkolja az interneten keresztül bejövő kártékony kódokat. Az adminisztrátor külön szabályrendszert állíthat fel a kimenő és a bejövő levelezésre vonatkozóan, ezzel egyszerűen és hatékonyan szabványosíthatja a cég levelezési elveit. Képes a levelek tartalmi szűrésére is, így az alkalmazottak produktivitásának növelése érdekében megvalósítható a nem üzleti jellegű levelek, a hoaxok és a lánclevelek blokkolása. - Trend Micro InterScan Web Security Suite: átjáró (gateway) szintű megoldás, amely a jelenleg legaktívabb vírusforrást jelentő interneten keresztül érkező fenyegetések ellen nyújt védelmet. Gondoskodik a kártékony kódok távoltartásáról, a HTTP, FTP protokollal átvitt fájlokban rejtőző vírusokat észleli és eltávolítja.

Ezek voltak azok a kolokációs szükségletek, amelyekkel - ha nem is teljes egészében – igyekeztünk érinteni az összes olyan területet, ami szóba jöhet. Mivel a valóságban minden egyes itt felsorolt pontért külön team felel, így biztos maradtak ki részek, illetve a felsoroltak is hiányosak, de igyekeztünk a tudásunkhoz képest a legtöbbet megemlíteni. A továbbiakban a hozzáadott szolgáltatásokról lesz néhány szó.

3.2. Az általunk használni kívánt eszközök főbb specifikációi Az alábbi táblázatokban találhatóak az említett specifikációk. IBM Storwize V3700 link Host interface Single/dual controller Cache per controller Drive type RAID levels

1 Gbps iSCSI (optional 8 Gb Fibre Channel or 10 Gbps iSCSI/Fibre Channel over Ethernet host ports) Dual controller 4 GB upgradable to 8 GB Dual-port, hot-swappable 6 Gb SAS disk drives RAID 0, 1, 5, 6 and 10

IBM System Networking RackSwitch G8000 link Ports 44 x 1 GbE RJ45 ports, 4 x 1 GbE SFP ports and up to 4 optional 10 GbE SFP+ or CX4 ports Power Consumption Low 120 W power consumption Virtualization VMready for virtualized networks 15


3. Szolgáltatás helyszíni/környezeti követelményei

PSU, Fans Configuration interface

Standard redundant power supplies and fans Simplified configuration with ISCL

Brocade VDX 6730 Converged Switch link Ports 24 x 10 GbE LAN ports and 8 x 8 Gbps native FC ports Cooling, PSU hot-swappable, redundant and integrated fan and power supply assemblies OS support Common Brocade Fabric OS supports the entire IBM System Storage SAN b-type family User Interface Open SAN management platform supports switch management through CLI, Brocade Web Tools or Brocade DCFM Protocols Supports multiple protocols including Fibre Channel over Ethernet (FCoE), iSCSI and NAS

IBM BladeCenter HS21 XM blade server link 2 x Intel® Xeon processors with 3 MB L2 cache per core CPU 4 GB (2 x 2 GB DIMMs) PC2-5300 667 MHz high-performance double Memory network Hot-swap I/O Warranty OS support

data rate (DDR2) ECC memory Dual Broadcom 5708S Gigabit Ethernet connections with failover support, support for Ethernet or Fibre Channel expansion cards Support for one non-hot-swap SAS SFF HDD Support for BladeCenter Storage and I/O Expansion Blade with three additional hot-swap SAS SFF HDDs and support for RAID 0, 1, or optional RAID 5 Warranty: Three years, customer replaceable unit (CRU) and on-site service3, limited warranty4 Microsoft, Linux, VMware, Novel (see link for detailed list)

3. 3. Hozzáadott szolgáltatások: Adottak a fizikai erőforrások, de még ebben a formábban semmire sem megyünk velük. Mivel Cloud alapú VPS szolgáltatás a megvalósítás célja így számos szoftveres megoldásra van még szükség. Cloud Computing elképzelhetetlen virtualizálás nélkül. Ahhoz, hogy szervereinket a lehető legjobban ki tudjuk használni, szükségünk van rá. Ezen felül szükségünk van a fürtözésre (cluster) is. Ennek segítségével egyrészt kiküszöbölhető a virtualizáció hátránya – mely szerint, ha a fizikai szerver kiesik buktuk a rajta futó virtuális hostokat is -, másrészt fürtözéssel egységesíteni tudjuk bizonyos szinten az erőforrásainkat és feladatokat tudunk átcsoportosítani egyik szerverről a másikra. 16


3. Szolgáltatás helyszíni/környezeti követelményei

Manapság három megoldás érhető el a felhő alapú virtualizáció területén. A szoftverek fejlesztői a VMware, a Microsoft és a Citrix. A VMware terméke az ESXi, a Microsofté a Hyper-V, a Citrixé pedig a XenServer. Az alábbi táblázat röviden tartalmazza ezen megoldások összehasonlítását.

Gyártó Termék Csatlakozók száma Memória Csomópontok maximális száma Futtatható virtuális gépek száma Virtuális processzorok maximális száma

VMware vSphere

Virtualizációs technológiák Microsoft

Citrix

Hyper-V Server 2008

Hyper-V Server 2008 R2

Windows Server 2008 R2

XenServer 6.0

10^8 255 GB + 255 GB

4

8

Enterprise: 8 Datacenter: 64

128

32 GB

1 TB

1 TB

128 GB

32

nem alkalmazható

16

16

16

320

192

384

384

75

8

8

8

8

16

Mi ezek közül a VMware megoldását fogjuk alkalmazni. Bár a hypervisor monolitikus kernelt használ, ettől függetlenül a gyártó folyamatosan szállítja az eszközilletőket, így ez nem jelent problémát. Az ESXi mellé szükségünk lesz még a vCenter licenszére is, hogy menedzselni tudjuk a clustereinket. A clusterek létrehozása után, engedélyezzük. Az ESXi-nek a hozzáférést az előzőleg már kiépített SAN adattárházunkhoz, és kész is vagyunk. Most már van egy magas rendelkezésre állásra kész, megfelelő Storage háttérrel rendelkező rendszerünk. Készen állnak a vasak a felhasználásra, most szükségünk van a szolgáltatás alapját nyújtó host operációs rendszerek beszerzésére. A Linux disztribúciókkal nem lesz probléma, tekintve, hogy ingyenesek, ellenben a Microsoft termékei licenckötelesek. Mivel VPS szolgáltatást fogunk nyújtani, így SaaS modellt fogunk alkalmazni. Ebből adódóan nem probléma a Microsoftos termékek használata sem, SoD (Software of Demand) formájában beszerezzük és biztosítjuk a leendő ügyfeleinknek. Ennek lényege, hogy mi rendelkezünk a software tulajdonjogával és az ebből fakadó költségeket fedezni fogjuk a szolgáltatási csomagokért kért bevételeinkből.

17


3. Szolgáltatás helyszíni/környezeti követelményei

A hostingra kínált OS-eket előre felkonfiguráljuk egy kezdőállapotra, majd ezt elmentve (erre a Norton Ghost-ot használjuk), egy előre ismert állapotról indítva (PXE booting) fogják tudni használni az ügyfelek. Ez számunkra azért előnyös, mert tudjuk, hogy mi van alapból az OS-ekben és egy szerverre felpakolva akárhány példányban telepíthetőek egy időben. A szolgáltatási csomagban kínált erőforrásokat pedig a clusterezett rendszerünk a háttérben automatikusan létrehozza scriptek segítségével, amint egy új felhasználó regisztrál az adott szolgáltatásra. Most következik a leginkább összetett része a szolgáltatás létrehozásának. Mivel webes felületen leszünk jelen, így szükséges egy olyan platform létrehozása, amelyen keresztül a felhasználók képesek menedzselni az általuk használt hardver-es és software-es megoldásokat. Ehhez ki kell fejlesztenünk a saját SOA architektúránkat. A SOA (Software Oriented Architecture) lényege, hogy az alkalmazások funkcióit szabványos platform független felületre vezetjük ki, és web szolgáltatásokat készítünk belőlük, melyek szabványos protokollokkal meghívhatóak. Univerzális XML alapú szabványok segítségével valósítható meg (WSDL, SOAP, UDDI). Esetünkben ez a következőképpen néz ki: a különféle funkciókat (pl: telepítés, felhasználói interakciók kezelése, módosítások véghezvitele stb.) fel kell bontanunk elemi darabokra, majd egységesíteni kell őket úgy, hogy aztán SOAP (Simple Object Access Protocol) protokollon keresztül ki tudjuk őket vezetni egy webes felületre (ami még nem látszik a felhasználó előtt). Ezt követően ezeket az elemi darabokat csoportosítva megkapjuk az alapvető funkciók weben keresztül elérhető változatait. Ez lesz a komplex web szolgáltatási réteg, ami még mindig rejtve van a felhasználók elől. Erre a rétegre le kell programozni a folyamatvezérlő réteget, aminek a feladata az egyes funkciók megfelelő vezérlése, szükséges háttérbeli scriptek lefuttatása (pl: regisztráláskor a megfelelő scriptek lefuttatása, amik létrehozzák a felhasználó által előfizetett erőforrásbeli környezetet). Legvégül erre létre kell hozni a felhasználói felületet. Itt szükséges a design, a felülettervezés és a minél átláthatóbb felhasználói környezet létrehozása. Szükségünk lesz még egy megfelelő CRM (Customer Relationship Management) rendszer felállítására is, egy megfelelő Trouble ticket rendszer támogatásával, annak érdekében, hogy probléma esetén, minél gyorsabban tudjunk reagálni azokra.

Ezek nagy vonalakban a hozzáadott szolgáltatások, amiket kezdésnek tervezünk. 18


4. Szolgáltatás üzemeltetés

4. Szolgáltatás üzemeltetése A szolgáltatás minőségének biztosítása, valamint a folyamatos fejlesztés, fejlődés érdekében az ITIL által megfogalmazott irányelvek lesznek az irányadóak. Mivel - a szolgáltatás bevezetéstől, az SLP és a különféle menedzsmentek (CRM, BRM, financial, demand, portfólió stb.) át egészen a szolgáltatásfejlesztésig – ezekről külön is kell dokumentációt, illetve pontos tervet készíteni, így - mivel a feladatnak ez már nem része – csak megemlítjük itt, hogy tudunk ezekről és a szükségességükről ahhoz, hogy hatékony és versenyképes szolgáltatást tudjunk nyújtani. Ezen felül tisztában vagyunk a Corporate IT feladataival, úgy, mint a szerverközpont üzemeltetés, az infrastrukturális szolgáltatások és telekommunikációs szolgáltatások üzemeltetése, a helpdesk, az alkalmazástámogatás, a biztonsági kérdések kezelése, az informatikai célú beszerzések kezelése, a stratégiai tervezés, a minőségbiztosítás és a resource management.

19


5. Üzleti modell

5. Üzleti Modell Az üzleti modell felállításánál figyelembe véve az aktuális piaci trendeket, megoldásokat, úgy döntöttünk, hogy a versenyképességet tartjuk a legfontosabbnak, ezért az árainkat/csomagjainkat is így állítanánk be. Csomag név: Memória: CPU: SSD: Adatforgalom: Ár

Induló 512MB 1 20GB 1TB 1.200Ft/hó

Haladó 1GB 1 30GB 2TB 2.400Ft/hó

Extra 2GB 2 40GB 4TB 4.800Ft/hó

Ultra 4GB 2 60GB 8TB 9.600Ft/hó

A felhasználóink havi bontásban fizetnének, illetve bizonyos akciók mellett választhatnának hosszabb időintervallumig tartó tervet is. A bónuszok a következők lennének: -

6 hónapos előfizetés esetén: 5% kedvezmény 12 hónapos előfizetés esetén 10% kedvezmény

A csomagokban foglalt adatforgalom túllépés esetén minden további 1GB adatforgalom 50Ft-ba kerülne az előfizetőnek. Csomagokat egy webes felületen értékesítenénk, továbbá csökkentett adminisztratív funkciókat is csatolnánk hozzá, mint pl.: -

telepítésnél OS választás előre definiált listából (Debian, ubuntu, CentOS, Arch, stb..) mind 32, mind 64 bites formában server újraindítás biztonsági mentés készítése domain kezelés

A kezelő fellület és publikus oldal egy külön szerveren helyezkedne el, a szerverközpontnak ez osztaná a jobokat. Tekintve, hogy sem árajánlatokat nem tudtunk szerezni a cégektől, sem nem kaptunk konkrét specifikációt arra nézve, hogy milyen tőkével is rendelkeznénk, ezért a beszerzési költségeket, illetve a beindításhoz, és üzemeltetéshez szükséges költségeket nem tudjuk részletezni.

20


proba