Virtuální servery - FAQ - otázky a odpovědi

Reverzní záznam je záznam uložený v DNS na DNS serverech obvykle poskytovatele konektivity, který slouží ke zjištění jména (nebo jmen) serveru, pokud znáte jeho IP adresu. Pro IPv4 platí, že záznam (jméno serveru) je v DNS uložen pod doménou in-addr.arpa, a to ve tvaru odpovídajícímu obrácenému pořadí bytů IPv4 adresy, které jsou vyjádřeny v desítkové soustavě. Pro IPv6 platí, že PTR záznam je v DNS uložen pod doménou ip6.arpa, a to ve tvaru odpovídajícímu obrácenému pořadí nibble (půlbajtů) IPv6 adresy, které jsou vyjádřeny v šestnáctkové soustavě. Krácený zápis IPv6 (vynechání nul) se nejdříve musí převést na úplný.

Pro IPv4 adresu 100.150.200.250 se tedy reverzní záznam vyhledává pod názvem 250.200.150.100.in-addr.arpa.

Pro IPv6 adresu 2a01:430:d:0:216:3eff:fe88:b6df se tedy reverzní záznam vyhledává pod názvem f.d.6.b.8.8.e.f.f.f.e.3.6.1.2.0.0.0.0.0.d.0.0.0.0.3.4.0.1.0.a.2.ip6.arpa.

Program host dostupný na většině operačních systémů dokáže sám poznat, že chcete reverzní záznam (pokud je argument IP adresa). Plná podpora IPv6 je dostupná až u relativně nových verzí host (vyzkoušeno - na Ubuntu 8.04 nelze přímo dotazovat IPv6, na 9.10 ano).

Virtualmaster automaticky nastavuje reverzní záznam k vaší IP adrese na vámi zvolené jméno serveru. Proto je vhodné, abyste zadávali název serveru ve formě FQDN. Virtualmaster v současnosti (2010-03-08) nenastavuje automaticky reverzní záznam pro IPv6. V případě potřeby kontaktujte podporu.

Pro mnoho internetových služeb (email, ftp apod.) je důležité, aby si dopředný a reverzní záznam odpovídaly.

Příklad správného nastavení reverzního záznamu:

jl@gromit:~$ host seznam.cz
seznam.cz has address 77.75.72.3
jl@gromit:~$ host 77.75.72.3
3.72.75.77.in-addr.arpa domain name pointer www.seznam.cz.
jl@gromit:~$ host www.seznam.cz.
www.seznam.cz has address 77.75.72.3

Zde je možné ilustrovat, že www.seznam.cz je FQDN, kdežto seznam.cz je alias.

Příklad nesprávného nastavení reverzního záznamu (2010-03-08):

jl@gromit:~$ host mvcr.cz
mvcr.cz has address 94.199.40.244
jl@gromit:~$ host 94.199.40.244
244.40.199.94.in-addr.arpa domain name pointer host-94-199-40-244.gov.cz.
jl@gromit:~$ host host-94-199-40-244.gov.cz.
Host host-94-199-40-244.gov.cz. not found: 3(NXDOMAIN)

Více o záznamech v DNS na Wikipedia DNS

DNS je zkratka pro “Domain Name System”. Jedná se o systém, který vznikl hlavně z potřeby převádět lidsky srozumitelná jména (např. www.vasefirma.cz) na IP adresy, kterým rozumí počítače. Systém je hierarchický a distribuovaný. Nejčastěji se používá hierarchie tříúrovňová, kde třem částem jména (www.vasefirma.cz) odpovídá postupné dotazování na třech úrovních DNS serverů (pro kořenovou zónu - tzv. root servers, pro národní nebo jinou doménu nejvyšší úrovně a nakonec se dotazují servery náležející k doméně druhé úrovně).

Systém DNS aktivně používá cache, takže v praxi je množství dotazů, které jdou zasílány na DNS servery ve vyšších patrech hierarchie, mnohem nižší, než by odpovídalo prostému součtu dotazů na nižším patře hierarchie.

Hlavní proměnnou, která ovlivňuje DNS cache, je TTL (zkratka pro Time To Live, “životnost záznamu”), která se nastaví individuálně u každého záznamu, nebo se použije výchozí hodnota pro celou doménu.

Důležité je, že při změnách v DNS se změna klientovi projeví v nejhorším případě až za 2x TTL, takže je nutné použít rozumné hodnoty, případně, před plánovanou změnou v DNS, TTL snížit. Praktické hodnoty TTL jsou mezi 5 minutami (např. při plánované migraci www stránek ze serveru s jednou IP adresou na server s novou IP adresou), a hodnotou v jednotkách dnů.

Více o DNS viz Wikipedia , Slovník ABClinuxu.cz

• používáte DNS servery od registrátora domény. V tom případě bude administrace DNS k dispozici přes webové rozhraní registrátora
• používáte vlastní (např. firemní) dns servery, jako např. ns1.vasefirma.cz a ns2.vasefirma.cz. V tom případě závisí postup vložení nového záznamu na použitém software.
• používáte DNS servery třetích stran, jako např. http://xname.org/
• nemáte vlastní doménu, nemáte DNS servery, nebo prostě nechcete vkládat záznam do žádné z vašich domén? V tom případě doporučujeme využít možnosti automatického vytvoření záznamu v doméně fqdn.cz, kterou máte na výběr při zakládání virtuálního serveru

FQDN je zkratka pro termín “Fully Qualified Domain Name”, což je volně přeložitelné jako “plně specifikované doménové jméno”. Opakem FQDN je například jméno v rámci lokální sítě. FQDN platí v celém internetu a má tvar obvykle hostname.domain.tld, kde tld je zkratka za “Top Level Domain”, neboli doména nejvyšší úrovně (např. .com, .cz, .eu), domain je doména druhé úrovně a hostname je jméno počítače. Více o FQDN zde a detailněji v angličtině zde

Doporučujeme našim zákazníkům, aby si v DNS zřídili A záznam, který bude obsahovat zvolené FQDN virtuálního serveru a povede na IP adresu, která jim byla přidělena při zakládání serveru. Nemáte-li doménu nebo nechcete-li ji pro daný účel použít, je možné zdarma využít vytvoření záznamu hostname.fqdn.cz

K Vašemu serveru se pak budete moci připojit pomocí jména místo toho, abyste si museli pamatovat nebo ukládat IP adresy:

ssh server.vasefirma.cz vs ssh 80.79.29.xxx

V případě IPv6 doporučujeme zavést do DNS AAAA záznam. Zde je rozdíl ještě markantnější:

ssh server.vasefirma.cz vs ssh 2a01:430:d:0:216:3eff:fe88:b6df

Prototyping je vytvoření funkčního prototypu, ověření použitelnosti zvoleného řešení.

Například vaše firma vyvíjí fotobanku. Fotobanka umožňuje 4 základní činnosti: zobrazovat náhledy fotek, vyhledávat, nahrávat nové fotky a (po zaplacení) stáhnout fotku ve vysoké kvalitě.

Vývoj trvá 1 rok. Po dobu vývoje potřebujete vývojové prostředí, prostředí pro testing a demonstrační verzi, ale na druhé straně máte málo uživatelů - testerů a tak prostředky vynaložené na provoz serverů chcete mít také malé.

Založíte si tedy jeden nebo více malých virtuálních serverů, dokončíte vývoj aplikace a před uvedením do ostrého provozu (kde dojde k velkému nárůstu požadavků) využijete možností škálování na platformě Virtualmaster a servery si zvětšíte podle zátěže nebo zátěž rozložíte na větší počet serverů.

Ušetříte tedy náklady v průběhu vývoje, pořizovací náklady na koupi vlastního HW a logistickou a administrativní činnost při nasazování vaší aplikace do ostrého provozu.

Tradiční model fungování počítače je třívrstvý. Na spodní vrstvě je hardware počítače (paměť, procesor, I/O zařízení), nad touto vrstvou běží jádro operačního systému (např. GNU/Linux, BSD kernel) a nad jádrem běží aplikace (např. WWW server)

Virtualizace zavádí čtvrtou vrstvu, která leží mezi vrstvou hardware a vrstvou jádra operačního systému. Jádro tedy nekomunikuje přímo s hardwarem, ale s virtualizační vrstvou.

Hlavními cíli virtualizace jsou: konsolidace (umístění více virtuálních serverů na jedno fyzické železo), získání hardwarové nezávislosti (změní-li se typ síťové karty hostitele, virtuální server to nepozná), minimalizace výpadků služby při údržbě hardware (možnost migrace virtuálního serveru na jiného hostitele, případně i live migrace).

Daní za provoz ve virtuálním prostředí je obtížnější řešitelnost úloh, kde se předpokládá přímá komunikace se specializovaným hardware (nepředpokládáme provoz počítače - řídící jednotky ultrazvukového vyšetřovacího přístroje u gynekologa ve virtualizaci), vyšší latence odbavování požadavků, určitá výkonnostní režie.

Strategie virtualizace jsou v zásadě dvě: paravirtualizace a virtualizace s emulací základního hardware počítače.

Paravirtualizace má nižší režii, avšak k běhu vyžaduje upravené jádro operačního systému. Emulace základního hardware počítače má vyšší režii, avšak nevyžaduje úpravy operačního systému.

Rozdíl mezi virtualizací a emulací spočívá v tom, že ve virtualizaci běží kód aplikací (které nepracují přímo s hardware) přímo na hostitelském CPU. V emulaci naproti tomu probíhá softwarová interpretace kódu procesoru, který je emulován.

Emulace tedy umožňuje spouštění operačního systému určeného pro jinou architekturu (např. pro ARM nebo MIPS na x86), kdežto u virtualizace se jedná vždy o shodnou architekturu, max. běží podmnožina architektury (např. i386 na amd64).

RAID1 je nejjednodušší redundantní diskové pole se strategií mirroring, neboli zrcadlení. RAID 1 diskové pole obsahuje dva nebo více pevných disků, které obsahují shodná data. Při zápisu se zapisuje na oba (všechny) disky najednou, při čtení je možné číst z libovolného disku. Toho se využívá při optimalizaci přístupové doby. Zápis je tedy o něco méně výkonný než u samotného pevného disku, čtení je o něco výkonnější.

Strategie RAID 1 chrání Vaše data před ztrátou v důsledku havárie pevného disku. V praxi je zapotřebí tuto strategii doplnit vhodným zálohováním. RAID 1 nerovná se zálohování. Pokud si například omylem smažete nějaké důležité soubory, RAID 1 vás neochrání, protože změny se ihned zapíší na oba (všechny) pevné disky.

U zálohování se obvykle uschovávají data inkrementálně, takže je možné obnovit data v několika bodech v minulosti. Pokud tedy například v pátek zjistíte, že ve středu došlo k odstranění důležitých souborů, je možné použít zálohu z noci z úterka na středu k jejich obnovení.

Ačkoliv je RAID 1 nejjednodušší diskové pole, jeho spolehlivost je nejvyšší. I když to nemusí být na první pohled patrné, složitější struktury jako např. RAID 5 nepřinášejí vyšší spolehlivost (a často ani vyšší výkon).

Škálovatelnost je termín označující možnost měnit výkon řešení v závislosti na růstu (poklesu) požadavků. Termín škálovatelnost se neomezuje na oblast IT, např. automobil se běžně škáluje pro převoz většího množství materiálu připojením vozíku. Obecně existují dva hlavní směry škálování - vyšší výkon jedné jednotky (např. blok jaderné elektrárny o výkonu 1000 MW místo 440 MW), nebo vyšší počet jednotek o menším výkonu (např. místo jednoho bloku JE o výkonu 440 MW dva takové bloky).

V prostředí virtuálních serverů se škálovatelností rozumí možnost přidávat (ubírat) prostředky virtuálního serveru (RAM, disk, CPU) nebo možnost přidávat (ubírat) celé virtuální servery. První možnosti se obvykle říká vertikální škálování, druhé možnosti horizontální škálování.

Vhodnost té nebo oné varianty závisí značně na konkrétní aplikaci. Například pro SMTP server, kde je požadavek na 200 současně možných spojení je možné snadno škálovat horizontálním směrem, protože jednotlivá spojení jsou na sobě zcela nezávislá. Tam je možné zvolit řešení se dvěma servery, z nichž každý bude mít kapacitu 100 spojení.

U web serveru je situace obvykle jiná. Jednotlivá spojení bývají na sobě závislá (např. data v session), takže při horizontálním škálování bývá nezbytné podniknout další kroky (např. session store v databázi a použití replikace). Nejčastěji se při škálování web serveru postupuje nejdříve škálováním vertikálním a potom teprve horizontálním.

S virtualmasterem máte možnost si škálování vašeho projektu vyzkoušet a můžete tak být připraveni reagovat na změnu poptávky.

Cloud computing je termín, kterým označujeme provádění velkého množství výpočtů nebo zpracování velkého množství dat apod. pomocí velkého množství (menších) serverů.

Jedná se o (extrémní) způsob využití škálování horizontálním směrem. Zajímavým vedlejším efektem v cloud computingu je možnost levného dosažení vysoké spolehlivosti.

Případ pro nasazení malého cloudu může být obsluha webu s vysokou návštěvností, zejména v případě, že dokážete odhadnou nárůst návštěvnosti v souvislosti např. s probíhající událostí, nebo s probíhající reklamní kampaní.

Typickým užitím může být například webová aplikace, kde trvá průměrně obsloužit jeden požadavek 100ms. Na web chodí tolik 2 milióny požadavků denně. Pokud by návštěvníci chodili na web rovnoměrně, bude potřeba 2,4 serverů na jejich obsloužení. Ve skutečnosti bude ale ve špičce potřeba 10 serverů. V případě aktuálně probíhající kampaně bude ve špičce potřeba 20 serverů.

Nejvíce ekonomickým řešením je udělat 2 servery - load balancery, např. s použitím haproxy nebo nginx a pak nakonfigurovat backend web server, udělat z něj šablonu a vyrobit 10 klonů. Máte-li zjištěno, že v noci a o víkendu je provoz slabý, můžete několik backend serverů v té době vypnout (load balancery to buď poznají samy, nebo jim o tom řeknete). Před spuštěním plánované kampaně přidáte 10 dalších klonů, které po ukončení kampaně zase odstraníte.

Jiným případem je např. optimální řešení jednorázové potřeby provedení určitých výpočtů. Příkladem může být práce na 3D filmu. Zde máte možnost zakoupit servery na renderovací farmu a po měsíci po skončení práce je zase prodat. Alternativně si můžete sestavit cloud na virtualmaster.cz a budete platit jen za počet serverů krát počet hodin, po který servery běžely.

Virtuální server si můžete zřídit okamžitě po registraci. Ihned po připsání kreditu si změníte parametry a úroveň virtuálního serveru do vámi požadované konfigurace.

Ano, je to možné, ale pouze v úrovni testing a v rozsahu limitů této úrovně.

Otestovat službu ve vyšším rozsahu je možné “zdarma” po zaplacení dostatečného kreditu, ovšem pouze po dobu do konce aktuálního účtovacího období (nejvýše tedy 1 měsíc). Navíc je nezbytné takové testování předem dohodnout a odsouhlasit s obchodníkem. Kredit, který jednou zaplatíte pak můžete použít k uhrazení jiných služeb. Pokud potřebujete otestovat službu ve vyšším rozsahu, kontaktujte laskavě technickou podporu.

I/O (IN/OUT) je termín označující všechny zařízení se vstupem a výstupem. V případě Vašeho virtuálního serveru se jedná o pevné disky a síťová zařízení. Agregace I/O určuje, kolik virtuálních serverů sdílí jeden disk a jednu síťovou kartu. Například agregace I/O 1:4 znamená, že váš virtuální server bude sdílet disk s dalšími čtyřmi virtuálními servery.

V případě, že jste se poprvé přihlásil pomocí hesla, pravděpodobně vám byl při přihlášení pomocí OpenID vytvořen zcela nový účet. V takovém případě je nutné provést spárování Vašeho OpenID účtu s Vaší identitou. V takovém případě kontaktujte podporu a počítejte s tím, že budete požádán o prokázání vlastnictví obou účtů (např. změnou údajů). Potom vám účty spárujeme.

Pokud problém je v obecné rovině mimo výše uvedené, ujistěte se nejdříve, že vám funguje OpenID přihlášení na jiné stránky. Potom sestavte co nejpřesnější zprávu o problému, zahrnující zejména:

• Vaši OpenID identitu
• Datum a čas posledního neúspěšného přihlášení
• IP adresu, odkud se přihlašujete (zjistit např. pomocí http://checkip.dyndns.org )

Kdykoli vám přestane vyhovovat aktuální konfigurace serveru, můžete si parametry serveru okamžitě změnit v "Detail serveru".

Můžete použít libovolnou doménu, u které máte možnost administrovat záznamy v DNS. Více o DNS. Pokud nemáte žádnou doménu, u které byste mohli (a chtěli) zavést potřebný A záznam do DNS, můžete využít služby fqdn.cz.

Na server samozřejmě žádné doménové jméno vést nemusí, avšak přihlašování přes IP adresy je nepraktické.

Ano, IPv6 konektivita je k dispozici, avšak zatím se IPv6 adresa virtuálním serverům automaticky nepřiděluje a nenastavuje. Pokud budete chtít využít IPv6 konektivitu, můžete svojí IPv6 adresu odvodit z IPv6 link local adresy pomocí:

echo -en "2a01:430:d:0:"; ip a | grep -A 4 eth0 | grep inet6 | grep "scope link" | awk '{print $2}' | cut -d : -f 3-

- výchozí brána pro IPv6: 2a01:430:d::1

Dále prosím kontaktujte podporu ohledně zavedení reverzního záznamu pro IPv6 do DNS.

Zálohování je zahrnuto v ceně virtuálních serverů v úrovní production. Po vytvoření serveru v úrovni production vám budou zaslány přístupové údaje do repositáře pro zálohování. K zálohovacímu repositáři se přistupuje pomocí SCP nebo SFTP protokolu.

Zpětně inkrementální zálohování probíhá v průběhu noci (mezi 01.00 a 07.00 CET/CEST) pomocí nástroje rdiff-backup na servery v jiném telehouse, než je provozován váš virtuální server. Aktuálně je k dispozici vždy celý obraz zálohovaného filesystému z poslední zálohy. Pokud potřebujete obnovit některou časovou zálohu, je potřeba stáhnout celý repositář a aplikovat na něj pomocí rdiff-backup rozdílové zálohy nebo kontaktovat podporu s požadavkem na obnovu konkrétních dat (cesty k souboru) z konkrétního data.

Můžete si vybrat z předinstalovaných distribucí: Debian GNU/Linux , CentOS , Ubuntu , Fedora a Gentoo . Nabídka se bude neustále rozšiřovat. Uživatelsky je možné vytvořit šablonu prakticky libovolného linuxového systému, který lze nainstalovat z běžícího linuxového systému. Seznam všech dostupných šablon je zde:

Možná řešení

• Nahrál jste si na server svůj SSH klíč? Pokud ano, zkuste se přihlásit po síti pomocí SSH.
• Jsou na serveru nějaká cenná data? Pokud ne, tak server jednoduše odstraňte a začněte znovu.

Pokud žádné uvedené řešení nevyhoví:

• vypněte server
• nabootujte rescue system
• přihlašte se jako root s použitím vygenerovaného hesla, které se zobrazí na konci boot sekvence
• zadejte příkazy:

# mount /dev/xvda /mnt
# chroot /mnt
# passwd 
# exit
# umount /mnt
# poweroff

Po vypnutí serveru, zapněte server běžným způsobem.

Ne, váš virtuální server je připojen přímo k internetu bez jakýchkoli omezení.

Ne. Naplánovat vypnutí serveru lze uvnitř virtuálního serveru pomocí běžných nástrojů, jako je at nebo cron a příkaz shutdown.

Zapnutí serveru je možné přes RESTfull API rozhraní, např. pomocí nástrojů cron a curl z jiného unixového serveru.

Agregace CPU definuje maximální možný počet virtuálních serverů sdílejících jedno jádro CPU.

Virtuální server je takový systém, který neběží sám na jednom hardware, ale podle určitých pravidel se o fyzický hardware dělí s dalšími virtuálními servery. Také přímo nekomunikuje s hardwarem fyzického serveru, ale komunikuje s ním prostřednictvím hypervizoru.

Image (obraz nebo také šablona) systému virtuálního serveru je zkomprimovaný oddíl s filesystémem s nainstalovaným operačním systémem, připravený pro vytvoření nové instance virtuálního serveru. V základních image jsou předinstalované potřebné nástroje pro automatické nastavení hostname, sítě a vytvoření uživatelů.

Předpřipravené image Virtualmasterem jsou co nejmenší a obsahují pouze základní programy. Vaše vlastní image serverů můžou obsahovat například kompletní konfiguraci Vašeho spam filtrového serveru, připraveného pro snadné škálování v případě velké zátěže a nebo instalaci Vašeho oblíbeného redakčního systému s kompletním hostingem. Fantazi při vytváření image se meze nekladou.

Seznam všech šablon naleznete na tomto odkazu.

Po vytvoření virtuálního serveru jste vy, jako administrátor vašeho nového serveru, zodpovědný za stav jeho systému. Veškerou údržbu, aktualizace a změny parametrů serveru si tedy provádíte sami.

Zmenšování RAM

Změna velikosti paměti směrem dolů je provedena vždy okamžitě. Pro projevení změny není potřeba u většiny distribucí restartovat server.

Zvětšování RAM

Doba zvětšování paměti je závislá na aktuální technické proveditelnosti. V případě, že není váš požadavek z technických důvodů možně uspokojit hned, je realizován v maximální možné míře a je vám odeslán informativní email o dočasné změně parametrů. Po úplném dokončení je odeslán email s finální konfigurací. Pro projevení změn velikosti paměti není nutné restartovat váš virtuální server

Zmenšování disku

Pro zmenšení velikosti disku Vašeho virtuálního serveru musíte mít ve filesystému alespoň 15 % volného místa. Změna velikosti je aplikována vždy až při následujícím startu Vašeho serveru. Doba trvání změny je závislá na velikosti disku, aktuálním rozložení dat, množství metadat apod.

Zvětšování disku

Doba zvětšování disku je závislá na velikosti disku a na aktuální technické proveditelnosti konkrétního požadavku. V případě, že není možné váš požadavek vyřešit ihned, je disk zvětšen na maximální možnou velikost a je vám odeslán informativní email o dočasné změně parametrů. Po úspěšném dokončení je odeslán informativní email s aktuální konfigurací. Proto aby se změna projevila uvnitř Vašeho serveru je třeba server vypnout a zapnout. Při startu serveru proběhne inicializace nové velikosti oddílu a změna velikosti filesystému.

Změna úrovně serveru

Změna úrovně je provedena vždy okamžitě. V případě, že provedete změnu na úroveň production, bude vám odeslán přístup k zálohovacímu repozitáři. V případě, že změníte úroveň virtuálního serveru z úrovně production na nižší, zálohovací repositář a všechny zálohy budou smazány.

OpenVZ není nástroj pro virtualizace v pravém slova smyslu, spíše se jedná o tzv. kontejnerování, někdy se též hovoří o měkké virtualizaci. S trochou nepřesnosti lze říci, že systém v OpenVZ je o něco lepší chroot, nejbližší konkurenční technologií pro OpenVZ je FreeBSD Jails nebo Solaris Zones.

U OpenVZ je velmi nízká míra oddělení virtuálního serveru od hostitelského systému a oddělení jednotlivých virtuálních serverů mezi sebou. Není možné použít jiný operační systém než Linux a není možné použít vlastní jádro nebo vlastní filesystém Výhodou je velmi nízká režie HW a snadná hromadná správa, pokud jste pánem celého hostitelského systému.

Xen je zástupcem “tvrdé” virtualizace, kde je vysoká míra oddělení virtuálních serverů od sebe. Daní za tvrdou virtualizaci je o něco vyšší HW režie, výhodou je pak zejména vyšší bezpečnost. Například v případě XENu můžete nezávisle aplikovat bezpečnostní aktualizaci jádra a poté provést restart.

Ne. Servery jsou virtuální, takže neexistuje fyzická reprezentace jednoho virtuálního serveru. Fyzické servery samozřejmě existují, ale fyzický přístup k serverům Virtualmasteru mají pouze pověření pracovníci, nikoliv klienti.

Zabezpečení dat vůči ztrátě se liší podle úrovně. U úrovní testing a personal není žádné zabezpečení.

Od úrovně production existují celkem 3 kopie dat, z čehož jedna kopie je umístěna v jiném telehouse, než váš virtuální server, takže data by neměla být ztracena ani v případě živelné pohromy, katastrofy apod.

Dvě kopie dat tvoří on-line replikace RAID1, třetí kopii dat tvoří off-line zálohování.

Při zabezpečení dat je vždy nutné kombinovat strategii RAID a strategii zálohování. RAID vás totiž neochrání proti nechtěnému smazání dat, záloha ano.

Zálohování probíhá pomocí nástroje rdiff-backup metodou zpětně inkrementální zálohy a to vždy v noci. U úrovně enterprise lze dohodnout vyšší třídu zálohování.

Zde záleží na zvolené úrovni služeb a rozsahu havárie. Pokud je služba typu testing, nemá žádné garance. Pokud je služba úrovně personal, data nejsou zálohována a tudíž nemůžeme garantovat obnovení virtuálního serveru ze zálohy, pokud dojde ke ztrátě primárních dat.

Od úrovně production výše jsme schopni garantovat obnovení serveru, avšak obnovení plné funkčnosti Vašich služeb může vyžadovat Vaší součinnost. Doba od vyžádání Vaší součinnosti (emailem, telefonicky) se nezahrnuje do celkové doby výpadku.

Poruchu řeší pověřený pracovník Virtualmaster a to tak, že vyhodnotí, zda je možné problém daného nodu opravit, nebo zda je nezbytné provést migraci virtuálních serverů na záložní node. Po ukončení opravy nebo migrace požádá zákazníky (od úrovně production výše) o kontrolu plné funkčnosti jejich virtuálních serverů. V případě podezření na chybu uvnitř virtuálního serveru požádá zákazníky o součinnost při řešení poruchy.

Z hlediska fyzické bezpečnosti jsou vaše data minimálně stejně bezpečná, jako v případě klasického hostingu fyzických serverů.

Mnoho hostingových firem s hostingem fyzických serverů má servery umístěné na polici, kde neoprávněné manipulaci (nebo i neúmyslnému zatažení za kabel) nic nebrání.

Servery, na kterých jede virtualmaster jsou zamčeny v racku a přístup do telehouse je monitorován.

Co se týče softwarového zabezpečení proti úniku dat, jsou všechny přístupy uvnitř virtualmasteru řešeny pomocí klíčů a certifikátů, takže nejvyšší zodpovědnost je nakonec stejně na uživateli.

• změňte si u všech virtuálních serverů nastavené heslo
• pokud je to možné, používejte klíče a certifikáty, případně dvou faktorovou autentizaci.

Konektivita je sdílená, v tuto chvíli 100 Mbps. U úrovně enterprise je k dipozici 1 Gbps. Předpokládá se, že větší část datového provozu virtuálních serverů jde do Česka. Abnormální datový provoz (zejména směřující tranzitním směrem) může být zpoplatněn částkou 3 Kč/GB.

Průměrné množství dat připadající na jeden virtuální server a měsíc je cca 10 GB, z čehož je cca 1 GB dat tranzitních. Za abnormální se považuje u třídy testing a personal více než dvojnásobek tohoto průměru, u třídy production pětinásobek a u třídy enterprise dvacetinásobek.

Ano, je to možné. V některých případech bude vyžadován restart serveru nebo jiná součinnost.

Právní podmínky provozu odpovídají platné legislativě. Vyhrazujeme si právo pozastavit poskytovanou službu bez předchozího upozornění, bez příkazu nebo souhlasu soudu v případě, že máme evidenci (nebo důvodné podezření) o abnormální aktivitě, jako je např. rozesílání spamu, hosting virů, malware a spyware, provozování command&control serverů botnetu, útoky hrubou silou, hosting porna (včetně legálního), špionáž, rhybaření a další.

Taktéž si dovolujeme upozornit, že v souladu s platnou legislativou provádíme sběr netflow dat, které můžeme na požádání poskytnout Policii ČR a jiným státním orgánům.

Použijte emailovou adresu abuse@virtualmaster.cz . Hlášení doprovoďte vhodnou evidencí. K odeslání použijte funkční a člověkem zpracovávanou adresu. Je preferováno použití ARF

Servery jsou fyzicky umístěny v pražských telehousech firem Sitel a Master Internet.

Bezpečnost dat má dvě stránky - jednou stránkou je zabezpečení proti úniku , druhou stránkou je zabezpečení proti ztrátě .

• Dostupnost 99% znamená možný výpadek v délce přibližně 7,2 hod., nebo několik kratších výpadků, kde součet jejich délky je max. 7,2 hod.
• Dostupnost 99,7% znamená možný výpadek v délce přibližně 2,2 hod., tedy asi 129 minut, případně též několik kratších výpadků, kde součet jejich délky je max. ca 129 minut.

Ke měření dostupnosti se hodí monitorovací systémy jako je např. Nagios . V Nagiosu je možné zobrazit “host availability report”, případně “service availability report”.