O StorSimple už jsem na tomto blogu psal. Jde o fyzickou nebo virtuální appliance, která nabízí funkce a rychlost lokální storage, ale přitom využívá cloud a je tak skutečně hybridní. Dnes si ukážeme jeho blokovou tvář, vyzkoušíme backup a disaster recovery.
Připomeňme si co je StorSimple
Jednak cloud funguje jako vzdálený tier, takže nejčastěji používaná data jsou dostupná lokálně, ale třeba 10x víc dat může být bezpečně uloženo v cloudu a vaše aplikace nebo uživatelé o tom ani nemusí vědět. Současně jsou všechna data v cloudu zálohována a můžete dělat snapshoty volumů či sharů stejně jako kompletní disaster recovery celého StorSimple. Při komunikaci s cloudem se vše deduplikuje, komprimuje a šifruje.
Ukažme si blokové nasazení
Při úvodním provisioningu StorSimple stačí zvolit režim iSCSI.
To je pak reflektováno v Azure portálu, kde centrálně svoje appliance spravujeme.
Pojďme si náš StorSimple nakonfigurovat.
Vybereme si storage account (místo, kde chceme mít cloud vrstvu a backup) a případně zapneme šifrování.
Připojím se na můj server, abych zjistil jeho jméno iSCSI iniciátora.
Vytvoříme si nový Volume z Azure portálu.
Vyplníme základní parametry a zadáme servery, které ho mohou využívat.
Na serveru si disk najdeme. Nejprve přidáme IP adresu StorSimple jako discovery portál.
Připojíme si disk.
Nastartujte správce disků - uvidíme tam nový disk. Pak stačí jen inicializovat a zprovoznit souborový systém.
V Linux můžete samozřejmě iSCSI disky použít taky. Nejdříve si zjistíme iSCSI jméno, abychom ho mohli v Azure portálu povolit pro přístup.
sudo cat /etc/iscsi/initiatorname.iscsi ## DO NOT EDIT OR REMOVE THIS FILE! … InitiatorName=iqn.1993-08.org.debian:01:e73a831b868
Pak stačí disk objevit, zalogovat se a najít v systému.
sudo iscsiadm -m discovery -t st -p 10.0.0.7 10.0.0.7:3260,1 iqn.1991-05.com.microsoft:win-ov8hneqgh58-mujdisk-target sudo iscsiadm -m node --login Logging in to [iface: default, target: iqn.1991-05.com.microsoft:win-ov8hneqgh58-mujdisk-target, portal: 10.0.0.7,3260] (multiple) Login to [iface: default, target: iqn.1991-05.com.microsoft:win-ov8hneqgh58-mujdisk-target, portal: 10.0.0.7,3260] successful. dmesg | grep sd [ 464.695559] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 464.707937] sd 6:0:0:0: [sdc] 1048576000 512-byte logical blocks: (537 GB/500 GiB) … [ 464.797207] sd 6:0:0:0: [sdc] Attached SCSI disk
V tento okamžik už použijete obvyklé postupy, tedy fdisk pro vytvoření partition, mkfs pro založení souborového systému a mount pro připojení.
Backup v cloudu
O výhodách zálohování v cloudu už jsem psal několikrát - máte data geograficky dostatečně daleko (tedy záplavy ve vaší lokalitě nezničí současně i zálohy), jsou uložena velmi spolehlivě a bezpečně v moderním datovém centru (případně i ve dvou regionech současně) s tím, že máte kontrolu v kde se budou vyskytovat, máte libovolnou kapacitu a platíte jen za to, co opravdu využíváte. Podívejme se, jak zálohuje StorSimple. Vyzkoušíme si to v nastavení pro share, ale podobně to jde se snapshoty volumů v blokovém případě.
Můžeme si nastavit pro nás ideální čas pro denní zálohy a prohlédnout si retention politiku.
Zálohu také můžeme samozřejmě vynutit manuálně v okamžiku aktuální potřeby.
Podívejme se na naše dosavadní zálohy.
Teď budu uživatel, který si smaže své soubory a pak prosí o pomoc. Smažu si všechny (možná už teď narazíte na záhadný adresář ".backup", který smazat nepůjde…vydržte, hned se k tomu dostaneme).
Vyzkoušejme první možnost - naklonujeme tento share z nějaké z našich záloh, tedy vrátíme se v čase do dne, kdy to bylo ještě v pořádku. To uděláme z pozice administrátora. Najděte si zálohu, která vám vyhovuje a vytvoříme její klon.
Vybereme název pro obnovený share.
Uživatel najde nový share a my jsme za hrdiny.
Uživatel má ale také možnost obnovit si přímo sám třeba jen jeden specifický soubor. Tím se dostáváme k záhadnému adresáři .backup. Uvnitř jsou adresáře začínající buď nějakým UUID (pro scheduled zálohy) nebo slovem Ad-Hoc (pro manuálně vyvolané) následované časovým razítkem. Uvnitř uživatel může najít co potřebuje a jednoduše si to přesune kam chce - zpátky do sharu nebo třeba jen na plochu.
Disaster recovery
Backup umožňuje vracet se v čase, obnovit data, ale co když přijdeme o celý StorSimple? V takovém případě můžete jeho kompletní nastavení obnovit z cloudu na jiný StorSimple, který lze umístit kamkoli na světě. Představme si tedy, že můj StorSimple skončil pod vodou.
Naštěstí jsem byl schopen rychle zprovoznit jiný v naší kancelářské budově a rád bych teď na něj překlopil obsah z toho havarovaného.
Nejprve musím storage, která plave ve vodě, deaktivovat.
Teď mohu provést Fail over.
Vyberu cílový StorSimple a celý proces může začít.
Průběh operace můžeme sledovat v záložce Jobs.
Po nějaké době bude disaster recovery dokončeno.
Uživatelé se teď k tomuto StorSimple znovu dostanou. Pokud jste museli appliance dát jinou IP adresu, bude pravděpodobně nutné ještě změnit DNS záznam (což je pro uživatele a servery transparentní).
Pinning
StorSimple si bude sám vyhodnocovat, jaká data jsou často používána a ty držet v lokálním tieru vs. přesouvat do cloudu. Máte ale také možnost některé shary nebo disky zakotvit a učinit je pouze lokální.
Tím máte jistotu lokálního výkonu a stále využíváte další hodnoty StorSimple, tedy backup do cloudu, centrální správu a disaster recovery možnosti.
Na co je StorSimple ideální volba a na co se nehodí? Pod Oracle nebo SAP ne, ale pro méně náročné aplikace nebo jako storage pro hypervisor v nastavení lokálního pinningu ano. Je perfektní pro sdílení souborů aplikacemi i uživateli, ideální pro distribuované nasazení (pobočky) nebo jako elegantní target pro zálohovací software. Příště si tyto scénáře rozpracujeme podrobněji.