Synology backup to Azure

A Synology otthoni és vállalti eszközei eddig is tudtak menteni a felhőbe (Azure, Amazon stb.), de tapasztalataink szerint míg egy otthoni környezettel (viszonylag kevés fájl, rövidebb fájlnevek és könyvtár struktúra) könnyen megbirkóztak, addig a KKV szektorban elég sok problémával találkoztunk: lassú mentés, kiforratlan logolás, időszakos leállások stb.

Alternatívaként felmerül a CloudBerry Backup használata is, de a meglávő eszközön, azonos fájlstruktúrával szintén nem birkózott meg. (Saját tapasztalat, egyéni környezetben, nem azt állítom, hogy a termék nem jó, mert máshol bevált!)

2016 március végén megjelent a DSM 6.0 a Synology termékekhez (nem minden eszköz támogatott!), melyben átdogozták a backup/restore eszközöket is. Ki is próbáltuk az ügyfeleknél és bizony az első tesztek nagyon biztatóak!

A HyperBbackup menüpontban érhetők el a beállítások:

image

 

A “rotációs beállítások” segítségével pontosan meghatározhatjuk, hogy az Azure Sorage-ben pontosan mennyi ideig szeretnénk megőrizni a korábbi mentéseket:

(Azure backupban retention policy-ként hivatkozunk rá)

image

 

Több 100Gb adatot feltöltöttünk az elmúlt napokban hiba nélkül, jó tudni, hogy a beépített Synology megoldások is fejlődnek és nem csak adatokat másolhatunk egy Azure tárolóba (a régi megoldás a DSM 5-ben tulajdonképpen csak ennyit tudott), hanem megőrzési időket, rotációt stb. is be tudunk állítani az egyes mentési feladatokra.

Próbáljátok ki a DSM 6-ot és mentsétek az adatokat az Azure felhőbe Mosolygó arc

Király István

kingsol.hu/blog

Microsoft Azure MVP

Reklámok

Renamed user logon name not synced Azure AD

Adott egy Office 365 előfizetés ahova szinkronizáljuk a helyi Active Directory usereket. Ez a szinkron tulajdonképpen a helyi AD és az Azure AD között zajlik, jellemzően egy irányban (föld—>ég Mosolygó arc ).

A szinkron bekapcsolása után jellemzően az user attribútumok csak a helyi infrastruktúrán módosíthatók (néhány kivételtől eltekintve, pl.: domain).

A helyben átnevezett user logon név (upn name) nem fog megváltozni az Azure AD-ban (az Office 365-ben).

Ezen a helyzeten segíthetünk PowerShell-el.

1. Legyen telepítve az Azure Active Directory Module for Windows PowerShell (64-bit version)

2. Csatlakozzunk az Azure AD-hez:

Connect-MsolService

3. Kérjük le a felhasználókat:

Get-MsolUser

4. Nevezzük át a felhsználó bejelnetkezési nevét:

Set-MsolUserPrincipalName -UserPrincipalName reginev@domain.hu  -NewUserPrincipalName ujnev@domain.hu

Király István

Azure MVP

www.kingsol.hu/blog

Makecert download link

Hétfőn megint demóznom kell (többek között) az Azure point-to-site VPN kapcsolatot is. Ilyenkor mindig generálnom kell tanúsítványt, melyet a makecert alkalmazással készíthetünk el a legegyszerűbben.

A makecert alkalmazás a Windows SDK része és a Visual Studio Community 2013 telepítése után elérhető az alábbi útvonalról:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin

Mivel most egy webes demórendszert fogok használni és nem a sajátomat, úgy döntöttem, ne legyen macera és felrakom a felhőbe a makecert.exe-t és hozzá egy txt fájlt is, rövid leírással.

Bármilyen demó alkalmával jól jöhet, és nem kell telepíteni több  GB adatot, VS 2013-at stb.

Akinek szükséges, használja egészséggel:

https://kingsolcloud.blob.core.windows.net/downloads/makecert.txt

https://kingsolcloud.blob.core.windows.net/downloads/makecert.exe

Király István

Microsoft Azure MVP

www.kingsol.hu/blog

remoteapp és linux desktop

 

A napokban érdeklődött egy ügyfél, hogy a www.remoteapp.hu oldalon hirdetett szolgáltatás RemoteApp része működik-e Linux desktop-on?

Nos, a válasz igen, ez is megoldható, csak egy winconn nevű ingyenes alkalmazás szükséges hozzá. A csatolt képen egy Azure infrastruktúrán működő, saját RemoteApp farmon futó, Excel 2013, Windows Media Player és Calculator látható Ubuntu 12.04 LTS disztribúción. A Winconn jelenleg nem támogatja az ennél újabb kiadásokat. (12.10-es és a 13.04-es verzió alatt is elindul, kisebb trükkökkel)

 

image

Király István

KingSol kft.

kingsol.hu/blog

Azure IaaS virtuális gépet ide nekem – de milyet?

Lassan 2 éve megy éles üzemmódban az Azure IaaS (ha jól tudom májusban lesz az), de sokszor olyan mintha már 20 éve lenne. Különösen azért, mert az újdonságak beborítanak, elárasztanak bennünket, a 6 hetes fejlesztési ciklusnak érthetően van egy ilyesfajta mellékhatása.

Éppen ezért időnként nem árt egy kis vérfrissítés, nézzük meg tehát rövid leírások illetve sok pepecselésselt elkészített táblázatok formájában, hogy jelenleg milyen sorozatú – és így milyen teljesítményű, kapacitású – virtuális gépeket választhatunk.

Tehát jelenleg 4 fő sorozatból áll az Azure IaaS géppark:

– “A” sorozat: Az átlagos gépek, a legtöbb felhasználó számára
– “D” sorozat: A gyorsítótárak királya
– “DS” sorozat: SSD gyorsítótárral az OS és az adatlemezek tekintetében
– “G” sorozat: A Godzilla típus, full extra

A száraz részletek előtt pár útbaigazító magyarázat:

– Egy Azure virtuális gép esetén minden erőforrás a géphez van rendelve, pl. egy logikai processzor esetén nincs time-sharing, vagy bármi más, közös használatra utaló megoldás.

– Nincs dinamikus memória, mint a Hyper-V-nél, minden gép fix memóriát kap, annyit, amennyit megjelölünk. Ennek előnye, hogy minden VM NUMA-val konfigurált, azaz képes kihasználni a NUMA előnyeit (pontosabban a NUMA érzékeny guest alkalmazások képesek erre), így a CPU és a RAM között a legjobb hozzárendelés érhető el.

– Az IOPS minden sorozatnál garantált az adatlemezek esetén (sorozattól függő a mértéke persze), azaz a Hyper-V-ben is egy ideje használható Storage QoS működik (vagy hasonló, ez elsősorban az én feltételezésem, nem teljesen kideríthető).

– Árakat direkt nem írok, mert ez nem az a blog :), másrészt regiónként és valutatípusonként is eltérőek lehetnek.

Az “A” sorozat

Ez a normál, legrégebbi típus. Nincs sok extra, van viszont sokféle gép, és olcsó. Sőt, egy ideje két ágra szakadt, a különbség egyszerűen definiálható:

– Basic: 300 IOPS adatlemezenként, nincs load-balancing (sem internal, sem external) és autoscale (de azért egy Availability Set-be rakható!), viszont átlagban 27%-kal olcsóbb mint az eredeti Standard

Azure-Basic-A-Series-VMs

– Standard: 500 IOPS, és minden fenti hiányzó képesség rendelkezésre áll. És ha jól megnézzül, azért itt is van egy hármas tagozódás, amit ezért 3 különböző színnel jelöltem ezeket. A nagy hálózati igényre kialakított A8/A9 igazi csemege 🙂

Azure-Standard-A-Series-VMs

A “D” sorozat

Viszonylag új sorozat, ami 2 extrával is bír, sokkal jobb CPU-ja van (kb. 60% az “A” sorozathoz képest), illetve az ideiglenes lemeze SSD, ergo az ide helyezhető, tipikusan nem maradandó fájlok (pagefile, SQL temp db), ultra gyorsak lesznek.

Azure-Standard-DS-Series-VMs

A “DS” sorozat

A Premium Storage bemutatkozó sorozata, minden adatlemez SSD! Megosztott, ezért kis mérettel indul, viszont akár 50000 IOPS és 512 MB/sec átviteli sebesség is elérhető így, ami igen szép eredmény., illetve nem-nem, ez nagyon durván szép eredmény!

Azure-Standard-DS-Series-VMs

A “G” sorozat

Nem véletlenül Godzilla a kódneve a tavaly novemberben, a barcelonai TechEd-en bemutatkozott sorozatnak. Ha pl. komplett SQL 2014 adatbázisokat akarunk a RAM-ban tartani, vagy tényleg durván nagy számításigényű gépekre van szükség (pl. HDInsight, Hadoop), akkor ez a mi terepünk.

A DS-hez hasonlóan itt is SSD fókusz van, de jóval több RAM-mal, és persze még újabb CPU-kal (Intel E5 v3). Ezek a virtuális gépek a legnagyobbak jelenleg, amit publikus felhőben (Azure, AWS, Google) megvehet az emberfia.

Azure-Standard-G-Series-VMs

A szokásos záró szlogen: minden sorozathoz, VM típushoz, mutatóhoz tegyük hozzá fejben a jelenleg szót 🙂

Gál Tamás

Az új Windows Server-ben…

… már Azure-ban is lehet a cluster-nél a quorum, úgy hívják Cloud Witness Disk. Teljes mértékben helyettesíti a Disk/File Share witness disk-et, és gyakorlatilag csak internet elérés egy Azure Storage fiók kell hozzá, semmi más.

Telephelyi clustereknél, vagy egy szabályos multisite cluster-nél a harmadik site-on elhelyezett file share witness-t például kiválóan tudja majd helyettesíteni, ami nyilván komoly anyagi megtakarítást is jelenthet. Én azért egy kicsit remélem, hogy idővel visszafelé is sikerül majd implementálni ezt a lehetőséget, azaz pl. egy Windows Server 2012 R2 failover cluster alá.

clustercloudwittness

image

image

Gál Tamás

Azure Automation változások

Nemrég írtam pár mondatban az Azure Automation szolgáltatásról, de azóta megváltozott pár dolog, gondoltam frissítem az információkat.

Az Azure Automation scriptek futtatására alkalmas szolgáltatás, mely nem olyan régen lépett csak ki a GA státuszba (General Availability).

Olyan powershell alapú szkripteket futtathatunk, melyeket eddig dedikált földi, vagy felhős gépek segítségével, a felhőben futó erőforrások kezelésére használhatunk.

Nézzünk egy példát úgy, hogy Azure AD felhasználó segítségét veszem igénybe

A script csak lekéri egy adott előfizetés gépeit, de szemléltetéshez elegendő most ez is.

1. Authentikáció előkészítése

Szükségünk van egy felhasználóra aki a megfelelő jogok birtokában le tudja kérni a VM-eket. Ehhez az Azure Active Directory-ban létrehozunk egy admin usert:

User felvétele: Azure Active Directory –> Default Directory –> Users –> Add user

image

Lépjünk be ezzel a felhasználóval és állítsuk be a jelszavát! Célszerű kikapcsolni a password policy-t is, hogy ne járjon le a jelszó érvényessége.

Az Azure AD password policy csak powershell segítségével módosítható:

Import-Module MSOnline

Connect-MsolService

Get-MsolUser -UserPrincipalName admin@istvankiralygmail.onmicrosoft.com | Set-MsolUser -PasswordNeverExpires $true

A nemrég felvett technikai usert-nek adjunk admin jogot:

Settings –> Administrators –> Add:

image

2. Automation fiók elkészítése és az authentikáció

Az Azure portálon válasszuk az Automation menüpontot és adjunk hozzá egy fiókot az előfizetéshez:

image

Válasszuk ki az elkészült fiókot, majd az Asset fülön válasszuk az ADD SETTINGS menüpontot!

image

Majd adjuk meg az authentikációs adatokat (username, jelszó)

image

3. Csatlakozás az előfizetéshez

Válasszuk megint az ADD SETTINGS gombot az alsó menüből és kattintsunk az ADD CONNECTION gombra!

image

A következő lapon adjunk egy nevet a csatlakozásnak és adjuk meg az előfizetés azonosítóját! (Portál, Settings menüpontban, de több más helyen is fellelhető)

4. Runbook

A runbook lesz maga a script. Írhatunk kedvünk szerint egyet vagy választhatunk az Azure Galériából is!

Válaszd ki az automation menüpontot, majd a jobb alsó sarokban NEW menüpont:

image

Kiválasztottam egy példa scriptet, mely lekéri a VMeket az előfizetésben. Ha ez működik akkor a többi script is tökéletesen fog működni, egyúttal megnézhetem a connection paramétereket is.

Példának ezt választottam a galériából:

Getting Started With Azure Automation – Get Azure VMs Using AD Authentication

Egy picit részletesebben a script:

$Cred = Get-AutomationPSCredential -Name “admin”

A connection asset felvételekor az admin nevet használtam erre hivatkozom most. Az “admin” mögött van az az AD user akit az imént felvettem és beállítottam rá a megfelelő password policyt.

$null = Add-AzureAccount -Credential $Cred

Azure előfizetés kiválasztása (az user egyértelműen azonosítani tudja)

$null = Select-AzureSubscription -SubscriptionName “előfizetés neve”

Az user egyérteműen azonosít egy tenant-ot, de itt lehet több előfizetés is amihez hozzáfér, ezért kell külön megadni ezt a sort, itt válsztom ki az előfizetést

Get-AzureVM | select InstanceName

ez maga a gépek lekérdezése

 

Mostantól készíthetek bármilyen Runbook-ot csak mindig illesszük be ezt a 3 sort az elejére, utána már jöhetnek a megszokott parancsok!

Ha valaki nem Azure AD userrel vagyis OrigID-val szeretne csatlakozni az előfizetéséhez, akkor másik opcióként választhatja még a certificate alapú azonosítást is!

 

Király István

www.kingsol.hu/blog

www.remoteapp.hu