Před 10 lety jsme jako jednu z našich služeb spustili sdílený hosting pod samostatným brandem HostingPark.cz. Za 10 let služba získala tisíce českých a slovenských zákazníků. Nyní službu HostingPark nahrazujeme o generaci novější službou s modernějšími technologiemi v cloudovém prostředí.
Co je to HostingPark
HostingPark.cz je služba sdíleného webhostingu a multihostingu od 29Kč měsíčně pro webové prezentace malého rozsahu.
Proč budeme HostingPark ukončovat
1. Zastaralost použitých technologií – HostingPark používá zastaralé technologie, zejména PHP verze 5.2/5.3 a s tím související další software, který již není mnoho let podporovaný autory.
2. Směr firmy – VSHosting se již mnoho let vydává cestou individuálních managed a cloudových služeb pro tisíce serverů a je v těchto službách největším providerem ve Střední Evropě. Díky špičkové infrastruktuře, například datacentru ServerPark, celoevropské datové a CDN infrastruktuře, využívají naše služby velké internetové projekty nejen v ČR.
Co služby HostingPark nahradí?
HostingPark nahrazuje modernější služba, která nemá na českém trhu obdoby. Je jí služba SnackHost Cloud Hosting.
Mezi její hlavní výhody patří:
1. Cloudové účtování per site, per day bez nutnosti předplácení a závazků 2. Dostupnost hostovaných webů až 99,999% díky cloudové technologii a high-availability 3. Podpora u běžného webhostingu neobvyklých technologií – SSH, GIT, Composer, drupal tools (drush, drupal console) 4. Garantovaný výkon 5. Neomezený diskový prostor 6. Let’s encrypt certifikáty 7. Volba PHP včetně verze 7.1 a možnost změny verze kdykoliv 8. Podpora MySQL (MariaDB) i PostgreSQL
Jde tedy o ideální multihostingové řešení nové generace, které v dnešní době využívá již přes 500 zákazníků. Služba byla spuštěna před více než rokem, je provozována naší dceřinnou společností a využívá stejně špičkovou infrastrukturu jako VSHosting.
Všem klientům, kteří ze služby HostingPark přejdou do služby SnackHost darujeme kredit ve výši 1000CZK a trvale nastavené ceny (netýká se domén) o 10% levněji. Po registraci nás stačí kontaktovat přes ticket SnackHostu nebo na konzultace@vshosting.cz?
Jsme Vám plně k dispozici pro poskytnutí součinnosti a rad, jak lze služby zmigrovat ze služby HostingPark do SnackHostu. Je pouze potřeba počítat s tím, že SnackHost podporuje PHP až od verze 5.4 (konkrétně 5.4, 5.6, 7, 7.1), PHP verze 5.2 a 5.3 tak již podporovány nebudou.
Jaký bude postup ukončení?
Registrace pro nové klienty na HostingPark.cz byla pozastavena již před rokem. Ukončení služby bude probíhat pozvolna a nejde o žádnou zbrklou hurá akci.
Postup ukončení: 1. Zasílání výzev k platbě (zálohových faktur) na roční prodloužení služeb bude probíhat až do 31.1.2018 (výzva na služby končící do 31.3.2018). Služby, které budou končit v období do 31.3.2018 tak budou mít možnost být ještě o rok prodlouženy, tzn do 31.3.2019 2. Služby, které budou končit po 31.3.2018, již nebudou prodlužovány a budou ukončeny na konci svého předplaceného období.
Jak si ulehčit přechod do synchronního MariaDB clusteru (Galera)
Využití MaxScale pro zjednodušení přechodu do clusteru, na který se dnes podíváme.
Řada velkých projektů, které využívají MySQL/MariaDB se již setkala s tím, že jim jednoduše nestačí provozovat jeden server či “hloupou” asynchronní master-slave repliku a že pro nutnost pohodlného horizontálního škálování musí připravit svoji aplikaci pro provoz databáze v MariaDB galera clusteru. To bohužel přináší poměrně zásadní předělání architektury aplikace, aby se vše přizpůsobilo vlastnostem clusteru, eliminovalo se riziko vzniku dead-locků a jiných komplikací.
vshosting~, jakožto největší Managed Services provider ve Střední Evropě, má s provozem náročných databázových clusterů mnoho zkušeností. Provozujeme v managed režimu na Galera clusteru například Shoptet, což je platformě pro více než 10.000 eshopů.
Pro zjednodušení části komplikací s přechodem do clusteru existuje nástroj zvaný MaxScale, na který se dnes podíváme.
Využití MaxScale při přechodu ze single node MySQL na MariaDB (Galera) cluster
Při přechodu z jednoinstanční mysql na cluster je obvykle nutné provádět aplikační změny, protože bězné balancování provozu přes tcp toho mnoho neumožňuje. Při takovém typu nasazení se pak obvykle stává, že se provádí transakční zápisové operace na více nodech nebo se čtou data z nodů, kam se ještě nestačila synchronizovat.
Potom je nutné vytvářet různé připojovací konektory do clusteru podle typu prováděné operace, případně upravit vlastnosti clusteru tak, aby na sebe nody vzájemně čekaly. To pak výkon clusteru snižuje. Při nasazení MaxScale se sloučí výhody tcp balancingu s přidanou logikou. Nejsou tedy nutné úpravy aplikace a provoz se směruje na jeden db konektor.
Pokud je cílem maximálně využít cluster, co se týká výpočetní kapacity a nenechat ho jen ve stavu vysoké dostupnosti, je možné vytvořit několik db konektorů podle typu použití např. Readonly pro rychlé čtení informací, readwritesplit pro automatické směrování zápisových operací a query caching pro dotazy, které se často opakují. To všechno pro dosažení maximálního výkonu clusteru.
Základní popis MariaDB MaxScale
MariaDB MaxScale je databázový proxy server, který rozšiřuje vysokou dostupnost, škálovatelnost a bezpečnost serveru MariaDB a současně zjednodušuje vývoj aplikací tím, že jej oddělí od základní databázové infrastruktury.
Zjednodušeně řečeno je to databázová proxy, která předává query do databáze na jeden nebo více databázových serverů.
MaxScale je navržen s rozšiřitelnou architekturou, která podporuje pluginy a rozšiřuje svou funkci nad transparentní vyvažování zátěže, aby se stala například databázovým firewallem. S vestavěnými pluginy pro více směrovačů, filtrů a protokolů může být služba MaxScale konfigurována tak, aby předala žádosti o databázi a upravovala odezvy databáze na základě předem definovaných požadavků – například k maskování citlivých dat apod.
Přesměrování se provádí pomocí pravidel, založených na sémantickém pochopení databázových query a rolích serverů v rámci clusteru databází.
MaxScale využívá rozsáhlé možnosti asynchronního I/O operačního systému Linux v kombinaci s pevným počtem pracovních podprocesů. Epoll se používá k zajištění události řízeného rámce pro vstup a výstup přes sockety.
Služby poskytované MaxScale jsou implementovány jako externí, sdílené, objektové moduly načítané za běhu. Běžně používané typy modulů jsou protokol, směrovač a filtr. Modul protokolu zajištuje komunikaci mezi klienty a MaxScale a zároven mezi MaxScale a backendy. Směrovač kontroluje dotazy od klientů a rozhoduje o cílovém backendu. Rozhodnutí jsou obvykle založena na pravidlech směrování a na stavu backendů. Filtry poté pracují s daty, které přes MaxScale procházejí.
Základní funkce
Firewall
MaxScale obsahuje filtr brány firewall pro blokování dotazů na základě pravidel nakonfigurovaných například na základě typu příkazu, použitých funkcí, vybraných sloupců nebo frekvence dotazů. MariaDB MaxScale 2.1 rozšiřuje filtrování na připravené příkazy.
Denial of service protection
MaxScale používá plugin omezující sadu výsledků query, aby se zabránilo dotazům, předpřipraveným příkazům a uloženým procedurám způsobit výpadek služby, vrácením příliš velkého množství dat. Maximální velikost sady výsledků query lze nakonfigurovat v řádcích nebo bajtech.
Read-Write Split
MaxScale obsahuje směrovač, který rozděluje čtení a zápis, když je sql server nakonfigurován jako multi-master (galera cluster) nebo master/slave (replika). Zápisy jsou poté prováděny jediným hlavním uzlem a čtení jsou prováděna na všech slavech – a to lze provést bez úpravy aplikace.
Change-data-capture
MariaDB MaxScale obsahuje protokol pro změnu dat, který v kombinaci s routerem Avro čte události binárního logu a přenáší je do klientů, kde mohou být data interpretována jako objekty Avro nebo JSON dokumenty.
Data masking
MaxScale používá filtr na maskování dat, který chrání citlivá data kontrolou výsledků dotazu a zmatením dat v určitých sloupcích na základě nakonfigurovaných pravidel. Při kombinaci s filtrem brány firewall databáze lze omezit přístup k citlivým datům.
Bulk insert streaming
MaxScale používá filtr pro hromadné vkládání insertů a přeměňuje všechny inserty v rámci explicitní transakce na jeden datový tok CSV pro přímé načítání s větší účinností, zlepšení výkonu a snížení síťového provozu.
Schema-based sharding
MaxScale obsahuje směrovač schémat pro podporu vícenásobného prostředí, kde každé spojení má vlastní schéma a schémata mohou být v různých databázích nebo vytvořit jednotnou logickou databázi z více fyzických databází – vše transparentní pro aplikaci.
Query caching
MaxScale používá filtr pro ukládání dotazů do mezipaměti, který zlepšuje výkon opakovaných dotazů a zároveň snižuje pracovní zatížení na podkladové databázi v závislosti na nastavených pravidlech – doba trvání, maximální počet řádků / velikost souborů, maximální počet záznamů apod.
Známá omezení / limity
Syntaktický analyzátor MaxScale správně analyzuje příkazy WITH, ale nedokáže shromáždit sloupce, funkce a tabulky používané v SELECTu definující klauzuli WITH. V důsledku toho databázový firewall neblokuje příkazy WITH, kde SELECT klauzule WITH odkazuje na zakázané sloupce.
Transakce XA nejsou zjištěny jako transakce MaxScale. To znamená, že všechny příkazy XA budou považovány za neznámé příkazy a budou považovány za operace, které potenciálně změní databázi (v případě readwritesplit jsou příkazy směrovány do masteru).
MaxScale nebude sledovat stav transakce XA, což znamená, že všechny dotazy SELECT prováděné uvnitř transakce XA mohou být směrovány na servery, které nejsou součástí transakce XA. Tomuto omezení lze na straně klienta zabránit vypnutím automatického vypnutí před provedením všech transakcí XA.
U filtrů není zaručeno, že obdrží kompletní pakety MySQL, pokud jsou použity s readconnroute směrovačem. To lze opravit pouze pomocí směrovače readwritesplit.
ReadWriteSplit
Čtení dotazů je směrováno na hlavní server I v následujících situacích:
* dotaz je spuštěn uvnitř otevřené transakce * dotaz je připravené prohlášení * příkaz obsahuje uloženou proceduru nebo volání UDF * pokud je uvnitř jednoho dotazu několik příkazů.
Věříme, že se vám náš dnešní článek líbil a chystáme pro vás řadu dalších odborných zajímavostí ;-).
„100Gbps marketing”, aneb jak se nenechat nachytat
100Gbps technologie není záruka kvalitního připojení. Dejte si pozor na následující faktory:
Pojďme se podívat na to, jaké prvky v páteřní síti hostingových firem či telekomunikačních operátorů reálně ovlivňují kvalitu připojení a dostupnost.
100Gbps – inovace nebo marketing?
100Gbps technologie je naprosto běžnou součástí páteřních sítí a ceny síťových prvků klexsají. Například Nexus 3232C, 1U switch disponující 32x 100Gbps porty vychází dnes po slevě kolem částky 300 000Kč: z pohledu páteřních sítových prvků drobná položka. Bez pochyb je dostatečná propustnost sítě naprostý základ stability, jde ale bohužel jen o jeden prvek, který je na tom všem reálně nejlevnější. Firmy chlubící se 100Gbps sítí ovšem často skrývají další aspekty sítě, které mají na reálnou spolehlivost větší vliv.
Čím se routuje?
Globální internet z pohledu počtu IP rozsahů propagovaných v routovacích tabulkách neustále roste. Je to zapříčiněno primárně tím, že z důvodu nedostatku IPv4 adres dochází na jejich „drobení“ až na malé rozsahy /24 a počet rozsahů v internetu tak roste.
Routery po světě, které od upstream providerů získávají plné routovací tabulky, mají mnohdy problém jakékoliv změny rychle přepočítat v rozumném čase. Často k tomu potřebují i více než 15 minut bez ohledu na to, jestli máte 1Gbps nebo 100Gbps. Routery jsou nejdražším prvkem v síti a často jde o nejslabší místo hostingových firem či providerů. Proto o routerech mnohdy vůbec nehovoří a chlubí se jen 100Gbps ?
Další naprosto zásadní otázkou je to, s kým je daná hostingová firma propojena a s jak kvalitním operátorem. Za kvalitního operátora s dostatečnou infrastrukturou lze označit Tier1 operátory, jejichž seznam naleznete i na wikipedii. Je totiž možné, že i při 100Gbps portu nakonec dojde k saturaci u upstream providera, například při útoku, a reálně 100Gbps v ničem nepomůže.
Je také vhodné se podívat, zda je daný operátor připojen do nějakého peeringového centra a jakou rychlostí a s kým je tak napřímo propojen. Propojení v rámci peeringového centra (například NIX.CZ) totiž zkracuje propojení a mezi hostingovou firmou a koncovým uživatelem tak odpadá „mezičlánek“ v podobě upstream providera.
To má pozitivní vliv na rychlost, náklady i spolehlivost a hlavně rychlost při konvergenci.
Příklad: daný operátor má nějaký výpadek a přepne provoz mezi více uplinků. Pokud jste s operátorem propojeni napřímo, routery se rychleji „domluví“ a data mezi vašimi sítěmi budou rychleji obnovena.
100Gbps připojením do NIXu disponuje například zatím jen Microsoft, Seznam, T-mobile, Justin.tv (viz veřejné statistiky) a několik málo dalších, kteří své statistiky na webu nixu nezveřejňují.
Čím může být dále poskytovatel omezen?
Řada providerů disponující 100Gbps technologií má ve své síti zapojeny prvky, které ovšem reálně 100Gbps neumí využít. K saturaci a omezení dostupnosti tak dojde i při řádově menším trafficu. Jde například o různé IDS/IPS sondy postavené na Linuxu. Datovou analýzu provádí procesor serveru a to je v řadě míst nejslabší článek, kde by bylo mnohdy nutné pro zvládnutí 100Gbps trafficu disponovat stovkami jader, aby bylo možné takový traffic v reálném čase vyhodnotit.
Ověřte si, jak moc je váš poskytovatel transparentní a zda zveřejňuje informace o tom, čím routuje, s jakými providery je propojen a jak reálně vypadá topologie sítě. Síťařina je samostatný a komplexní obor a marketing firem se často schovává za líbivé pojmy jako „100Gbps síť“. Ve vshosting~ něco takového považujeme za samozřejmé :-). Do roka budeme pravděpodobně vzhledem k nárůstu trafficu upgradovat uplinky do NIXu ze 40Gbps na 2x 100Gbps.
Damir Špoljarič
