Synology NAS újra… | Asteriksz's Blog
Kezdőlap > General, Windows Server	> Synology NAS újra…
Synology NAS újra…
szeptember 9, 2011 Asteriksz	Hozzászólás Go to comments
A múltkori cikkemben írtam, hogy milyen beállítást szükséges elvégezni ahhoz, hogy a Windows Backup ne hasaljon el. Sajnos ezzel nem lehet véglegesen lezárni az ügyet, ugyanis kiderült, hogy ha a “strict allocate = yes” opció be van kapcsolva, akkor nagy méretű (értsd kb. 16+ GiB) állományok esetén a másolás hibára fut:
Windows 2008 R2 esetén:
Windows 2003 R2 esetén:
Total Commander-el:
Az igazsághoz hozzátartozik, hogy W2k3 esetén a hibaüzenet ellenére átmásolta – de számomra továbbra sem volt barátságos a hibaüzenet. Ha a Windows Backup miatt átállított kapcsolót visszaállítjuk, csont nélkül át tudunk másolni bármekkora állományt.
Nem hagytam ennyiben, ismét felvettem a kapcsolatot a gyártóval. Eleinte értetlenkedtek, de végül úgy tűnik megértették a problémát, s azt a választ kaptam, hogy felveszik a hibalistára, s ha más is jelzi, akkor foglalkoznak vele – állítólag én vagyok az első, aki ilyen dologra vetemedik, hogy Windows Backup-ot és SMB megosztást is akarok használni, kapcsolgatás nélkül. Ráadásul a javaslatuk az volt, hogy használjak más módszert, például FTP-t.
A válasz nem volt kielégítő számomra, így tovább nyomultam. Mivel nemrégiben volt szerencsém egy Dlink tárolóhoz, s azon kipróbálva minden elsőre működött (rejtett kapcsolók, stb. nélkül), ezért jeleztem a Synology-nak, hogy ugyan már, ne a Windows-ra fogják a hibát.
A további levelezésben kiderült, hogy bár nekik nem sikerült előidézni a hibát (s mindenképp a Windows backup vhd-kezelésére fogják a hibát), mindenképpen szeretnének foglalkozni a problémával – így remélem hamarosan kapunk rá megoldást. Addig az általam nem elfogadott FTP helyett az iSCSI elérést javasolták. (Mellékesen a srácok valóban nem tétlenkednek, hiszen nemrég kijött a 3.2-es DSM is, mely egy csomó újítást hozott. Többek között például a Raid-kötetek – általam is kifogásolt – létrehozási ideje pl. több óráról alig pár percre csökkent – pontosabban a felhasználó elől elrejtve, a háttérbe került).
Bár nem mondhatni nagy kedvencemnek, körbejártam ezt a lehetőséget is.
Egy LUN létrehozásánál alapból felajánlott “Thin provisioning” esetén ha létrehozunk egy LUN-t, akkor a neki dedikált terület mérete nem kerül levonásra a teljes szabad kapacitásból. Magyarul csak akkor csökken a kijelzett szabad terület, ha valóban másolunk a tárolóra valamit, függetlenül attól, hogy ezt az SMB vagy az iSCSI által szolgáltatott területre tesszük.
Ez a technika ugyanakkor lehetővé teszi azt is, hogy sokkal nagyobb méretű LUN-t hozzunk létre, mint akár a teljes NAS mérete – ekkor ugyanis elvileg további merevlemezekkel bővítve a tárolót, kiterjeszthetjük a LUN-t rájuk is.
Szintén a technikából adódik az is, hogy létrehozhatunk több LUN-t, amelyek méretének összege meghaladja a tároló méretét – magyarul ugyanazt a területet osztjuk ki több egységnek. Értelemszerűen ez csak addig nem gond, amíg van megfelelő szabad tárterület, de ilyenkor azért fokozott figyelemmel kell kezelni a LUN-okat.
Aki játszadozott már más tárolókkal, annak sokkal ismertebb lehet a “Thick provisioning” technika (Synology esetén az előző kapcsolót Nem-re kell állítani). Ekkor a LUN-nal kiosztott kapacitás lefoglalásra kerül, csökkentve a szabad kapacitás mennyiségét – még akkor is, ha a logikai egység teljesen üres.
Mindkét esetben igaz, hogy a LUN-ok méretét növelni lehet, csökkenteni viszont nem – még akkor sem, ha teljesen üres, soha nem használt logikai egységről van szó. Ugyanakkor a logikai egység formátumán (vékony/vastag) sem tudunk utólag változtatni.
Még mielőtt továbbmennénk, még egy dolgot érdemes tudni. A Synology két típusú LUN-t tud létrehozni/kezelni: az állomány-szintű (saját megnevezésében “Regular files”) és a tömb-szintű (vagyis “Block-level”) egységeket. Előbbi esetén zöld jelölést kapnak a LUN-ok, s fizikailag egy állomány lesz belőlük (ez válasz egyik kolléga kérdésére is J), míg utóbbi esetén kék színű grafika jelöli őket – s ekkor az alatta levő lemezeket/kötetet közvetlen módon érik el. Értelemszerűen egy SHR-el (Synology Hybrid Raid) létrehozott köteten csak zöld LUN-okat tudunk létrehozni, hiszen ott már létezik egy állomány-rendszer… (Bővebben erről itt)
Ha megvagyunk a LUN-ok kialakításával, következik a Target-ek létrehozása. A legegyszerűbb megközelítés esetén minden kiszolgálóhoz (amelyik akarja ezt a tárolót iSCSI-val használni) létrehozunk egy saját Target-et, majd ehhez rendeljük hozzá a szükséges LUN-okat. A fentiekből gondolom sejthető, hogy egy LUN-t több Target-hez is hozzá lehet rendelni (erről mindjárt még esik szó). Természetesen egy szerverhez lehet több Target-et is kiosztani, ha netalán “1 LUN/1 Target” elképzelést valósítunk meg. Ha egy Target-hez szeretnénk több kiszolgálót rendelni, akkor ezt is engedélyezhetjük egy pipával – ez viszont mindenképp megfontolást igényel (jellemzően fürtözésnél szokták ezt használni).
Akár közös Target-ről, akár közös LUN-ról van szó, a végeredmény szempontjából mindegy: ugyanazt a logikai egységet akarják használni. Erre mindenképp figyeljünk, hiszen a kiszolgáló bizonyos esetben csak akkor látja a másik által elvégzett módosításokat, ha előtte bontja, majd ismét felépíti a kapcsolatot a tárolóval. Sőt, még ilyenkor sem lehet egyszerre írni, mert az egyik biztosan elvész (a bontás/újbóli felépítés kiszolgálói sorrendjéből fog következni, hogy mi megy az örök vadászmezőkre) – tehát ez a megoldás nem javasolt.
A Target-ek általában Ready állapotban kerülnek létrehozásra, ha valamilyen hiba miatt Offline állapotban lennének, akkor az Enable gomb lenyomásával tudjuk őket kész állapotba hozni. A két állapot ikonja között nincs különbség – ellentétben azzal, amikor csatlakoztatjuk a kiszolgálót a célhoz, ekkor ugyanis az ikon egy sárga “zebrát” kap.
Az én problémám esetén (természetesen, csodálkoztam volna, ha itt is gondok lépnek fel) az iSCSI segítségével csatolt meghajtókra simán lehet másolni és menteni is a Windows Backup-al – így már csak megint tervezési kérdés lett a dologból…
március 23, 2012 - 12:35 du.
Synology DSM 4.0 | Asteriksz's Blog
szeptember 14, 2012 - 1:08 du.
Synology DSM 4.1 « Asteriksz's Blog
Scom 2012 (Beta) gondolatok Hyper-V to Windows Virtual PC