Hogyan válasszunk VPS szolgáltatót?

Nem céljunk bemutatni, hogy mi az a VPS, ezzel kapcsolatban rendgeteg írás olvasható az interneten, úgyhogy ugorjunk oda, amikor eldőlt a kérdés: már biztos, hogy VPS-re van szükséged. Itt jön a nagy dilemma: mi alapján érdemes választani rengeteg VPS szolgáltató közül? Ebben próbálunk segítséget nyújtani.

Magyar vagy külföldi szolgáltató?

 

A kommunikáció sebessége

Amennyiben a VPS-nek nem csak a számítási erőforrásait vagy háttértárait használod egy adott célra, hanem Te, vagy a célcsoportod sokat kommunikál vele - tehát számít az adatforgalom sebessége - akkor célszerű a célcsoporthoz fizikailag minél közelebbi VPS-t választani. Ha a VPS pl. webszerverként üzemel, és a rajta hosztolt honlapok célközönsége magyar, akkor érdemes Magyarországhoz közeli vagy még inkább magyar szolgáltatót választani. Hogy a nagyságrendek láthatóak legyenek, megpingeltünk néhány szervert amerikában, angliában és magyarországon, ezután átlagoltunk, kerekítettünk, és az alábbi adatok jöttek ki:

  • USA ~ 200 ms
  • UK ~ 50 ms
  • HU ~ 15 ms

Látható, hogy igen nagy különbségek adódhatnak. Ha a célcsoport külföldi, akkor a dolog hasonlóan érvényes: a célcsoporthoz közeli országban működő szolgáltatókat érdemes előnyben részesíteni. Ha webszerver lesz a VPS-ből, akkor az elhelyezésnek SEO szempontból is lesz némi szerepe.

Kommunikáció az ügyfélszolgálattal I. - nyelv

Magyar szolgáltató esetén jó eséllyel nem ütközhetsz nyelvi nehézségekbe, bármi egyéb esetben adódhatnak gondok. A VPS szolgáltatóval akár a megrendelés során, akár menedzselt VPS beüzemelése/üzemeltetés során a felmerülő feladatok kapcsán, rosszabb esetekben hibabejelentés során kommunikálni kell, és hiába angol a kommunikáció nyelve, előfordulhat, hogy a problémádat egy az angolt nem anyanyelvi szinten beszélő (pl. indiai) kollegával kell megértetned, mert mondjuk az adott cég a support centert kiszervezte. 

Fizetésmód

A szolgáltatásért fizetendő díj kiegyenlítésére magyar cégek esetén átutalás és csekkes befizetés az elterjedt megoldás, külföldi szolgáltató esetén jellemző a bankkártyás fizetésmód (dombornyomott kártyát igényel) vagy PayPal. Hogy melyik a jobb vagy előnyösebb, mindenki döntse el maga..

Kommunikáció az ügyfélszolgálattal II. - telefon/email/ticketing rendszer

Az előbb említett nyelvi gondoknál nagyobb probléma lehet az, hogy egyes, jellemzően külföldi és nagy VPS szolgáltatók nem adnak meg telefonos elérhetőséget, vagy megadnak ugyan valami számot, de azon csak értékesítő kollegákat lehet elérni, műszaki embert nem. Így egy esetleges időkritikus szerverleállás esetén is marad az email vagy üzenet írás a ticketing rendszerbe. Amikor egy kritikus szolgáltatás áll, a szervert Te sem éred el, és az ügyfelek, akik a VPS-en futó szolgáltatást használnák, percenként telefonálnak, hogy mégis mi várható, mi történt, és telefonos kontakt hiányában nem tudod senkitől azonnal megkérdezni, hogy mégis mi a helyzet, elszáltt valami hardver, tudnak-e egyáltalán a dologról, hol tart a hiba javítása, fél órán belül megoldódik vagy csak egy nap múlva... Ez a szituáció igen idegőrlő tud lenni. Dobálod be a hibajegyeket a szolgáltató felé, és minden perc, amit a válaszra való várakozással töltesz, óráknak tűnnek. Tehát nem árt, ha a VPS szolgáltató elérhető telefonon, esetleg skypeon. 

Kommunikáció az ügyfélszolgálattal III. - ügyfélszolgálat "nyitvatartása"

Megvan, hogy milyen nyelven, megvan, hogy milyen csatornán érjük el a segítséget, most jön a harmadik kérdés: MIKOR? Egyes magyar tárhelyszolgáltatók, VPS szolgáltatók kényelmesen, a munkaidőben nyújtanak supportot (tisztelet a kivételnek). A szerver ugye nem csak munkaidőben üzemel, tehát ebben az esetben a nap 2/3-a gyakorlatilag nincs lefedve, azaz egy meghibásodás esetén 66% esélyünk van rá, hogy olyankor történik gond, amikor nem elérhető az ügyfélszolgálat. Tehát válasszunk olyan szolgáltatót, akinek 365/24/7 elérhető az ügyfélkszolgálata. Esetleg ha lehetőségünk van rá, teszteljük is ezt.

Kommunikáció az ügyfélszolgálattal IV. - ügyfélszolgálat hozzáértése

A VPS szolgáltatónál is emberek dolgoznak, akik magasan képzett informatikus szakemberek. Vagy nem. Egy eddig sosem tapasztalt hibajelenség, egy szokatlan igény, mind-mind okozhat gondot. A nagy, nemzetközi szolgáltatóknál nagyobb eséllyel lesz mindig (tehát nem csak most, hanem később is...) egy olyan szakember, akinek eszkalálják a különleges prolémánkat, és ő azt megoldja.  Nagyobb cégeknél szintekre van bontva az ügyfélszolgálatos csapat, az apró-cseprő vagy mechanikus, rutin dolgokat az alacsonyabban képzett, olcsóbb munkaerő oldja meg, a fejtörést igénylő kérések mennek a guruknak. Egy kisebb cégnél jó esetben csak guruk dolgoznak, de ha nincs szerencsénk, akkor adódhatnak meglepetések. Ez a szakértelem kérdéskör sajnos nehezen mérhető, így esetleg fórumokon, illetve egyéb weboldalakon lehet utánaolvasni, hogy másoknak mi a tapasztalata a kiszemnelt szolgáltató support csapatával. Persze erre sem biztos, hogy érdemes alapozni, mert a cégeknél a munkaerő és szakembergárda cserélődhet.

Kommunikáció az ügyfélszolgálattal V. - az ügyfélszolgálat válaszideje

Szintén nehezen mérhető, de probléma esetén kardinális kérdés, hogy az adott kérésünkre, problémánkra milyen gyorsan ad megoldást a szolgáltató. Néhányan a honlapjukon feltüntetik, hogy a beérkező hibajegyeket milyen határidőn belül kezelik le. Nyilván minél rövidebb időt gatantálnak, annál nyugodtabbak lehetünk.

Stabil, megbízható cég

Mindenképpen stabil, régóta működő céget érdemes választani, mert ha a szolgáltató tönkremegy vagy nem megfelelő szolgáltatást nyújt, rosszabb esetben akár nagy fejtörést is okozhat egy másik szerverre vagy VPS-re való átköltözés, főleg akkor, ha a szerver IP címére több olyan domain név mutat, amelyek DNS szervereit nem mi menedzseljük.

Rendelkezésre állás

Mindig kardinális kérdés, hogy milyen rendelkezésre állást vállal egy adott szolgáltató. Elmondható lenne, hogy minél több kilences szerepel benne, annál jobb a szolgáltató, de ez nem feltétlenül igaz, helyette érdemes elolvasni az ÁSZF-et, hiszen hiába vállal a szolgáltató 99,999%-os rendelkezésreállást, ha az ÁSZF szerint ennek a rendelkezésre állásnak a nem teljesítése esetén mondjuk csak a befizetett havidíj erejéig térítenek vissza pénzt, esetlgeg még azt sem. Így, bármilyen felelősség és anyagi kockázat nélkül egyes cégek nyugodt lelkiismerettel tüntetnek fel vevőcsalogatás céllal több kilométernyi kilencest. Persze elviekben minden szolgáltató célja az, hogy a szolgáltatása kiesés nélkül üzemeljen, hiszen ekkor lesz elégedett az ügyfél, de VPS szolgáltató és VPS szolgáltató közt igen nagy különbségek lehetnek, hogy mit tesznek meg a kimaradások elkerülése érdekében.

Érdemes végiggondolni, hogy szolgáltatáskiesés miatt mi mekkora kárt szenvedhetünk: ügyfeleket, látogatókat veszíthetünk. Ez sokszor összemérhetetlen nagyágrendű kár az adott VPS bérleti díjához képest. Ha az esetleges kár katasztrofális jellegű, a melegtartalékról lehet, hogy érdemes nekünk gondoskodni a többletköltségek dacára. Hiába olvashatunk varázslatos self-healing, raid X, SAN storage, cloud hostig és egyéb megbízhatóságot sugalló szavakat, csak erre ne hagyatkozzunk. 

A szolgáltató által használt hardverek

Erről sok szolgáltató nem ad információt, vagy csak homályosat. Pl. "első osztályú Dell szerverek." Nem sokat mond. Érdemes olyan szolgáltatót választani, aki nyílt lapokkal játszik. Nem csak a hardverek gyártója, kora, minősége, teljesítménye számít hanem az architektúra is. És itt elérkeztünk egy mostanában igen divatos fogalomhoz:

Cloud

Mit remél az ember a hangzatos "cloud hosting" feliratot olvasván? A megszokottnál nagyobb hardveres redundanciát ("self healing"...) jobb skálázhatóságot, kevesebb problémát. Nekem eddig az elmúlt 3 év során - mely idő alatt 4 VPS szolgáltatót használtam különböző országokban - csak a Cloud architektúrát használó szolgáltatónál volt adatvesztésem és hoszabb szolgáltatáskiesésem. Nem is egyszer, hanem háromszor. Állítólag nagyon kevés ügyfelet érintett a dolog és csak az általam használt nodeon voltak gondok. Na de kéremszépen, "self healing" virított a szolgáltató nyitólapján, SAN háttértárak, miegymás, de akkor hogy is van ez? Esetemben állítólag az adatok tárolására használt SAN-nal történő kommunikációban voltak gondok egy driverhiba miatt. 

Az architektúra bonyolításával a meghibásodás valószínűsége is nő, és noha sok esetben a redundáns hardverek át tudják venni a meghibásodottak feladatát, de mindig van néhány SPOF (singe point of failure), és ha itt történik a meghibásodás, akkor hiába az egyes elemek redundanciája.

Emellett azért van megkérdőjelezhetetlen előnye a cloud architektúrának: amennyiben tudjuk, hogy pár hónap vagy év múlva több erőforrásra les szükségünk, mint jelenleg, akkor érdemes ilyen hardverrel dolgozó szolgáltatót választani, mert itt jóval kisebb esélyünk van arra, hogy a későbbi hardverszükséglet többletünket ne tudnák majd kiszolgálni, tehát egy körülményes költözéstől kímélhetjük meg magunkat. Egy adott hardvert "feldaraboló", nem cloud megoldáson üzemelő VPS esetében limitálva van az adott hardver erőforrása, és nem biztos, hogy a szolgáltató az IP címünk megtartása mellett könnyedén tud az adott szerveren több erőforrást adni vagy másik hardverre zökkenőmentesen átköltöztetni.

Egyes cloud szolgáltatók lehetőséget biztosítanak arra, hogy időszakosan vegyünk igénybe erőforrásokat a felhőben. Például ha a szervernek minden hétfőn 9-12 közt nő meg a terhelése, akkor lehetőség van erre az időre plusz CPU vagy memória bérlésére (automatikusan), így nem fog lassulni a szolgltatásunk. Ilyenkor fizetni csak erre a néhány órára kell az erőforrásokért, tehát jelentős költségcsökkentés érhető el egy olyan megoldáshoz képest, amikor fixen fizetünk a nagyrészt kihasználatlan erőforrásért.

Overselling

Bizonyos virtualizációs technikák lehetőséget adnak arra a szolgáltatónak, hogy több erőforrást (jellemzően memória és processzor) osszon ki, mint amennyivel rendelkezik. Teszik ezt abból amegfontolásból, hogy úgysem fog minden ügyfél egyszerre maximális terhelést adni a szervernek, mindig lesznek olynok, akik épp kihasználják az erőforrásokat, és lesznek olyanok, akik épp nem. Utóbiak miatt lesznek tehát olyan erőforrások, amit mások felhasználhatnak. 

Az overselling tehát az, amikor a rendelkezésre állónál több erőforrást értékesít a szolgáltató egy adott hardveren.

A probléma abból adódhat, hogy nem zárható ki teljesen, hogy mégis esetleg egy adott időpontban minden VPS maximális erőforrást szeretne igénybe venni, így az erőforrások elfogynak. Ráadásul ha már belekezdett a szolgáltató a túlértékesítésbe, akkor általában nem egy kicsivel ad el több erőforrást, hanem igyekszik azt az optimumpontot megtalálni, ahol a profit maximális és még "az ügyfél is épp ki van szolgálva", ezen a ponton egyensúlyozva könnyű átcsúszni az "ügyfél már nincs rendesen kiszolgálva" oldalra, ekkor furcsa dolgokat produkálhat a szerverünk, lelassulhat, memória hibákba ütközhetünk. Vagy vérszemet kap a szolgáltató és szinte konstans túlterhelt szerverekkel szolgáltat, ilyet is tapasztaltunk már itt a magyar piacon az egyik legolcsóbb cég esetében.

Tehát érdemes olyan szolgáltatót választani, aki vagy azt állítja magáról, hogy nem értékesíti túl a hardvereit, vagy méginkább: aki olyan virtualizációs technológiát használ, ami nem teszi lehetővé a meglevőnél több erőforrás eladását.

Virtualizációs technológiák

A témáról könyvek szólnak, itt most csak az előző fejezetben leírtak alapján szeretném szétbontani a manapság elterjedt virtualizációs megoldásokat, azaz hogy lehet-e az adott technológiával túlértékesíteni.

Operációs rendszer szintű virtualizáció, izolció, konténer virualizáció: Ebben az esetben a guest és host kernel ugyanaz, ami több problémát is felvethet. Tehát kernel szinten is a szolgáltatóhoz vagyunk kötve. Az olcsó VPS szolgáltatók általában ilyen megoldással dolgoznak. A legelterjedtebb ilyen virtualizációs megoldások a virtuozzo és openvz (előbbi nyílt változata)

A full system/native virtualizáció és paravirtualizáció esetén már jobban szeparálva vagyunk a host kerneltől illetve a többi VPS-től, ezek esetében kevésbé számíthatuk az overselling problémájára. Elterjedtebb virtualizációs megoldások ezekben a kategóriákban: Xen, VMware, VirtualBox, KVM

IP címek

Szükség lehet egy VPS-hez több IP címre. Érdemes már az elején megvizsgálni, hogy van-e lehetőség több IP cím VPS-hez rendeléséhez, és azt is, hogy ennek milyen költségei vannak. Egyes VPS szolgáltatók eleve több IP címet adnak a "kezdőcsomagban", mások csak egyet.

Menedzselt vagy nem menedzselt?

A Menedzselt VPS esetében valamilyen formában rendszergazdai segítséget kapunk a VPS céljainka történő bekonfigurálásában, tehát az installálást és beállítást jellemzően elvégzik helyettünk a szolgáltató munkatársai. Ezen felül az üzemelés során felmerülő kérdéseket, felmerülő igényeket megoldják. A menedzslet VPS-ek általában jelentősen drágábbak, mint a nem menedzselt szolgáltatások, ahol magunknak kell mindent beállítani. Utóbbi esetben egy "alap" előtelepített operációs rendszert kapunk. Ha nincsenek megfelelő ismereteink (vagy ismerőseink :)) a szerverkonfigurálás terén, akkor javasolt menedzseltet választani. Ezzel az az eset is elkerülhető, amikor mi úgy gondoljuk, hogy a szolgáltató hibájából nem működik valami, ők pedig azt állítják, hogy mi nem jól konfiguráltunk be valamit, hiszen menedzselt VPS esetén a szolgáltató feladata beállítani mindent úgy, hogy az hibátlanul működjön.
Van ezen kívül egy köztes megoldás, ahol ugyan nem menedzselt szolgáltatást veszünk, de igénybe vehetjük szolgáltató rendszergazdéinak szaktudását óradíj vagy ticket alapon.

Admin felület

Komolyabb, jellemzően cloud szolgáltatóknál admin felületről "on the fly" vásárolhatunk plusz memóriát, CPU kapacitást, háttértárat. Ez jól jöhet, viszont ha ehhez nem is, ahhoz mindenképp ragaszkodjunk, hogy egy VPS konténer újraindítási lehetőségünk legyen (jellemzően webes felületről), mert igen idegtépő tud lenni, amikor lefagy a szerver, és egy operátorra kell várnunk - akinek pl. egy ticketing rendszeren keresztül jeleztük a problémát - hogy újraindítsa a VPS-ünket.

Mentés

Kardinális kérdés, hogy ki gondoskodik a mentésről. VPS esetén a szolgáltatók ugyan általában tükrözött vagy egyéb RAID architektúrűban üzemelő diszkrendszeren tárolják adatainkat, de ez nem helyettesíti a rendszeres mentést. Legtöbb szolgáltató nem biztosít mentést VPS csomagokban, így vagy érdemes egy másik VPS-t bérelni a célra, vagy egyes helyeken a VPS díjának töredékéért bérelhetünk a VPS-hez járó merevlemez kapacitással megegyező méretű "csak háttértár mentési célra" szolgáltatást. Ide magunknak kell rendszeresen felszinkronzálni adatainkat. Alternatív adattárolás (akár) mentési célokra: Amazon S3. Egy bevált mentési megoldás beállításairól olvashatsz korábbi cikkünkben.

Ár

Anyagi lehetőségeink eltérőek, így objektív iránymutatásnak az ár kérdéshez csak annyit tennék hozzá, hogy hosszú távon nem biztos, hogy az olcsóbb havidíjú szolgáltatás lesz az olcsóbb. Ha egy szolgáltatás a piacon a legolcsóbbak közt van, akkor érdemes gyanakodni, és kideríteni, hogy hol spórolták meg a többi szolgáltatóhoz képest mutatott árkülönbséget. Pl. gyengéb hardverek, kisebb/kevésbé szakértő/kevesebbet dolgozó munkatársak stb. Egy esetleges szolgáltatáskimaradás miatt történő ügyfél elvesztés vagy egy kényszerköltözés sokkal drágább lehet / sokkal nagyobb veszteséggel járhat számunkra, mint egy kicsivel drágább, de jobb szolgáltatást nyújtó VPS szolgáltató kiválasztása - már az elején.

Amazon EC2

Ugyan nem nevezném VPS-nek, de ahoz igen hasonkó szolgáltatás az Amazon EC2. Egy VPS-hez képest legnagyobb hátránya a statikussága. Egy AMI-t (Amazon Machine Image) hozunk létre, ez felel meg a VPS-en futó szoftvernek. Gyakorlatilag ugyanazt tudja, mint egy VPS egészen addig, amíg újra nem kell indítani, mert újraindítás után visszaáll az image alapállapotába, tehát a futás során képződő adatok tárolásáról külön kell gondoskodnunk (pl Amazon S3 szolgáltatásal). Hátránya itt szerintem ki is merült, előnyeiről oldalakat lehetne írni. (olcsó, annyit fizetsz amennyit használsz, skálázható, megbízható, stb.)