Sokszor keresnek meg minket azzal a kérdéssel, hogy melyik hosting szolgáltatásunkat ajánljuk egy bizonyos vállalatnak, folyamatnak, igénynek. Egyesek olyan megoldást keresnek, ami olcsóbb, de később felfelé skálázható, mások, inkább a magas rendelkezésre állás és a georedundancia miatt lettek az ügyfeleink.
Ahhoz, hogy egy érdeklődő biztosan jó döntést hozzon a tekintetben, hogy ügyfelünk lesz-e vagy nem, illetve hogy melyik a számára legmegfelelőbb megoldás, 3+1 kérdést kell alaposan végig gondolni. Ha ez a három plusz egy megvan, a többi tulajdonképpen részletkérdés.
1. Irodai szerverterem vs. profi szerverterem
Ez a döntés azoknak szól, akik számára rendelkezésre áll egy saját, irodai szerverterem, vagy gondolkoznak ilyen kialakításán.
Természetesen egy irodai szerverterem is rendelkezhet megfelelő körülményekkel, amik a szerver üzemeltetéséhez feltétlenül szükségesek. A hűtés és hálózat lehet jól méretezett, lehet tűzvédelem, és a vagyonvédelem is megoldott általában egy irodaházban. A megfelelő körülmények és a profi körülmények között viszont nagy különbség lehet.
Miket tesz meg egy profi szerverterem azért, hogy a szerverek ne álljanak le? Először is eleve redundáns, szünetmentessel ellátott áramforrásokkal dolgozik, vagyis több, egymástól független betáplálás is érkezik a szerverterembe, mindegyike alkalmas a teljes rendszer ellátására. Ha mégis mindkét betáplálás megszűnne, a szervereket az akkumulátorok működtetik tovább, amíg be nem indul a dízelaggregát. Ha pedig a dízelaggregát nem indul, ott egy másik dízelaggregát. Annak, hogy ez mind egyszerre menjen tönkre, a rendszeres karbantartás mellett, szinte nem látható esélye van.
De nem csak az a veszély fenyegeti a szervereket, hogy nem kapnak elektromos áramot. Természetesen fontos a megfelelő hűtés, a tűzvédelem, a vagyonvédelem, sőt fontos a szerverek számára elérhető sávszélesség, amiből mi…
…redundáns és garantált belföldi és külföldi sávszélességet biztosítunk!
Redundáns, ami azt jelenti, hogy több helyszínen vesszük át a hálózati forgalmat úgy, hogy rendelkezésünkre áll e tekintetben egy olyan méretű végponti és hálózati gerinc adatkapcsolat, hogy ügyfeleinknek garantálni tudjuk minden századmásodpercben az ígért sávszélességet. És nem csak belföldre: ismerünk olyat, hogy egy szolgáltató mikróval csatlakozik, mellette pedig egy 100 megás vonalat kapnak, amin van egy nagyon kicsi külföld. Nálunk, ha valakinek 10 giga külföldet adunk, akkor neki mindig tudjuk ezt biztosítani. Ez azért nem gyakori a szolgáltatók körében.
Aki pedig még ennél is biztosabbra szeretne menni, annak elérhető egyszerre több RackForest szerverterem. Jelenleg három is van Budapesten, ezek redundánsan összekötve még nagyobb rendelkezésre állást biztosítanak (lásd ezen cikk 4-es pontja). A telephelyek közötti nagy sévszélességű optikai összeköttetések garantálják a nagy adatforgalmat és kis késleltetést, a háromszögelés pedig garantálja a redundáns kapcsolatot egy estleges optikavágás esetén.
2. Vásárlás (hoszting) vs. bérbevétel (bérszerver)
Ez a döntés azoknak szól, akik feltétlenül dedikált, tehát kizárólag a cégük számára fenntartott fizikai szerverben vagy szerverekben gondolkoznak (akiknek ezt nem feltétlenül igénylik, ugorjanak a következő kérdésre).
Itt arról kell dönteni, hogy meg szeretnénk-e vásárolni egy saját szervert – esetleg vannak már saját szerverek, és ragaszkodunk hozzájuk -, majd azt el szeretnénk helyezni egy profi környezetben, vagy bérelnénk inkább egy dedikált szervert, ami természetesen eleve ugyanott, a szolgáltató termeinek egyikében található. Nyilvánvaló, hogy ha vásárolunk szervert, az nagyobb indulási költséggel jár, a bérlés esetén nincs ilyen, az első naptól csak a bérleti díj ketyeg.
És hogy mennyi? Egy saját, “hozott” szerver hosztingja a RackForestnél 15.900 forintos havidíjról indul. A legkisebb bérszerver 21.990 forint havonta (bár még van 1 db 18.900 forintos, Intel Haswell processzoros is). Néhány ezer forintos különbségről beszélünk tehát, és a hoszting megoldásban nincs benne részünkről sem maga a szerver, sem a support csomag.
Amit sokan összekevernek, hogy a bérlés nem lízinget jelent. Nem arról szól, hogy a szolgáltató megvásárol egy szervert, amit részletekben kiszámláz az ügyfélnek, a szerverbérlés egy szolgáltatás. Mi két óra alatt garantáljuk a hibás hardver cseréjét. Nagy szerver brandek azt vállalják, hogy három óra alatt kiszállnak a helyszínre. Azért ez is óriási különbség.
Tehát
szerverbérlés = fizikai, dedikált szerver biztosítása + hoszting a szolgáltatónál + support csomag
A hoszting és a bérlés között tehát ez a legszemléletesebb összefüggés.
A szerverbérlés alapvetően sokkal rugalmasabb. Egyrészt azért, mert ha csak kis időre kell a szerver, így nagyon olcsón használhatunk egy egyébként drága vasat. Ha például bizonytalan az adott projekt hosszú távú léte, ez kétségkívül jobb megoldás lehet, de ugyanúgy jobb azoknak, akik kicsiben indulnának, majd fokozatosan növelnék a kapacitásokat. Egy nagyobb bérszerverre upgrade-elni sokkal kevesebb munka az ügyfélnek, mint egy új saját szervert vásárolni. Olyan is előfordul, hogy az ügyfél egyelőre nem tudja, mi a helyes konfiguráció számára. Nem tudja, hogy az alkalmazása processzorban, RAM-ban, IO-ban hogyan terheli majd a vasat, vagy hogy elég-e a SATA diszk, esetleg SSD kell. A bérszervernél az a jó, hogy ezt ki kehet kísérletezni, élesben. Ahogy megszületik az igény egy más konfigurációra, vagy a háttértárak cseréjére gyorsabb változatra, már meg is történhet a váltás.
Egy érzékletes példa erre: ha a saját szervernél derül ki egy idő után, hogy 12 darab SATA diszket kell SSD-re cserélni, akkor az újra egy nagyon magas költséget jelent, és ott marad a kérdés, hogy mihez lehet kezdeni a kiszerelt diszkekkel?
3. VPS vs. dedikált bérszerver vs. private cloud
Ez a döntés mindenkinek szól, hiszen a kis számításigényű feladatoktól a hatalmasokig itt megtalálható minden megoldás.
A VPS (Virtual Private Server) azt jelenti, hogy nincs egyetlen, saját dedikált szervere egy adott előfizetőnek, hanem egy szerveren több előfizető is osztozhat, egymástól természetesen “elzárva”. A virtuális gép erőforrásait az ügyfél maga választja ki, és idővel, ha több erőforrásra van szükség, egyszerűen csak jelzi az új értékeket, és egy egyszerű újraindítás után az új konfiguráció lesz érvényes. Általában kisebb számításigényű feladatokra ideális (például akár 1 GB RAM-tól indulva lehet igényelni VPS-t, míg a bérszerverek 8 GB-ról indulnak), valamint akkor, ha gyorsan szeretnénk módosítani a konfigurációt, a forgalmunk függvényében. Hátránya, hogy részben közös erőforrások vannak – a memória és a háttértár minden ügyfélnek dedikált, de a processzor és a hálózat nem -, így ha például az egyik ügyfelet támadják (doSolják), azt sávszélességben átmenetileg a többi ügyfél is megérzi.
Van, hogy egy ügyfél időnként nagy számítási igényű feladatot küld a VPS-re, ekkor például ezt úgy oldottuk meg, hogy egy másik, több szabad kapacitással rendelkező VPS-re tettük át, hogy ne zavarja átmenetileg sem a többieket. Az ügyfél természetesen nem vett észre ebből semmit, a migráció azonnal és fennakadás nélkül megtörténik.
A dedikált bérszerver azt jelenti, hogy minden erőforrás egy helyen, egy szerveren található. Az ügyfél nem osztozik senkivel, de nem is osztja meg sok szerver között az erőforrásokat. Egy bizonyos gépigény felett már nem lehet VPS-t igényelni, ott már muszáj bérszerverben gondolkozni – viszont több száz gigabájt RAM-mal és több terabájtnyi tárhellyel lehet ellátni a vasat. Bővebben a 2-es pontban.
A private cloud azt jelenti, hogy több dedikált bérszervert összefűzünk egy halmazba. Ha az ügyfélnek már több dedikált bérszervere van, akkor ezeket egyetlen stack-ben látja, egyetlen, nagy erőforrásként. Ezen belül tud az ügyfél virtuális gépeket létrehozni és futtatni. Tehát lehet, hogy valakinek van három szervere, ami futtat öt virtuális gépet, az erőforrások megosztása pedig a háttérben, észrevétlenül megtörténik.
Ennek egy fokkal bonyolultabb verziója a hibrid cloud, amikor egy private cloud bérlő, egy bizonyos nagy forgalmú időszakra VPS-eket is bérel a private cloud mellé. Ilyen is előfordult nálunk, tipikusan karácsony táján.
+1
1 lokáció vs 3 lokáció (georedundancia)
Ez a döntés azoknak szól, akik feltétlenül nagyon nagy rendelkezésre állású megoldást keresnek, amik esetében még inkább lecsökkentik a szolgáltatás alacsony leállási kockázatát.
A HA cluster (High-availability cluster) azt jelenti, hogy a szerverek csoportját úgy üzemeltetik, hogy azok minimális leállással működhessenek. A cikk elején biztosított védelmeken túl ilyenkor érdemes a gépeket szétszórni több fizikai helyszínen, hogy ha az egyik láb kiesik, a másik kettő még elvihesse a vállán a feladatokat. Vagy, más esetben, csak a szolgáltatások egy része álljon le, a többi változatlanul működhessen.
Nem mindegy azonban, hogy a több láb hol, milyen szolgáltatónál nyugszik. Mi három lábat javaslunk, jó sávszélességgel (x10Gbps), így csökkenthetjük minimálisra a kockázatot. Épp ezért mi kialakítottuk a RackForesten belül ezt a három helyszínt, mindegyik helyszín 40Gbps optikával csatlakozik a gerinc hálózatra. A több lábon állás (elosztott rendszerek) kritikus pontja a szinkronizálás, ami el tud vérezni akkor, amikor nincs elegendő sávszélesség a gyors és nagymennyiségű adatátvitelre. Volt már olyan, hogy az ügyfél két lábat hozzánk, egyet pedig egy nagy nemzetközi szolgáltatóhoz vitt, de folyton szétesett a szinkronizálás, mert a bérvonalon nem tudták garantálni a szükséges sebességet. Amikor a harmadik láb is nálunk volt, minden működött, ahogy kell.
Nálunk a három terem olyan, mintha egy nagy szerverterem lenne, több kilométeres távokkal, független árammal, hűtéssel és hálózati kapcsolatokkal. Mint a szervetermek private cloudja, ha ideillő, érzékletes hasonlatot szeretnék keresni.
Ha a fenti 3+1 kérdést végiggondoljuk, akkor van esélyünk, hogy gyorsan jó döntést hozzunk a vállalkozásunk számára. Természetesen mi is segítünk, várjuk megkeresésüket speciális igényekre vonatkozóan, illetve ha bármi kérdésük van, bombázzanak minket nyugodtan (legfeljebb beállítunk plusz erőforrást gyorsan:))
RackForest szolgáltatások:
További cikkek:
Mi alapján válasszak SSD-t a szerverembe? Milyen SSD élettartamra számíthatunk?
Jönnek a 10 nm-es Intel CPU-k, de 3-4 évet kell várni a 7 nm-esekre
Miért várjuk ennyire az AMD idei EPYC szerver processzorait?
Nagyon pörög a Docker és Ansible, de kezd túlpörögni
