Milyen DFS-t? + WebDav kérdések

Sziasztok! Egy kisméretű céghez szeretnék distributed file system -et telepíteni, két darab Linux-os gépre. Az lenne az ötlet, hogy egy sima tükrözött merevlemez helyett két darab webdav kiszolgálót csinálnék. Ennek az lenne az előnye, hogy ha tönkremegy az egyik gépen BÁRMI akkor még a másikon keresztül el lehet érni az állományokat. Ezt azért szeretném így, mert sajnos már előfordult hogy táp hiba miatt leállt az egész és ki kellett mennem. Az szeretném elérni, hogy 100%-os redundancia legyen. Tehát ha az egyik gépben tönkremegy bármi, a szolgáltatás akkor is elérhető maradjon, és ne kelljen azonnal rohannom a céghez.

A következő kérdések merültek föl bennem:

* Ha a DNS nevére round robin van, akkor a Windows 10 webdav-os mount azt jól kezeli? (Tehát pl. elszáll az egyik gép akkor a HTTP request átmegy a másik gépre automatikusan?)

* Milyen DFS-t használjak? Semmi tapasztalatom nincs ebben, ezt olvasgattam: https://en.wikipedia.org/wiki/Comparison_of_distributed_file_systems ez alapján a sok zöld cellás megoldások érdekelnek. Melyik az ami hibatűrő, és nem igényel nagyon sok konfigurálást? Előnyt jelentene ha lehetne snapshot-okat csinálni, de enélkül se rossz.

* Extra webdav-os kérdés: eddig még mindig Samba-t használtam, de nagyon eljárt fölötte az idő. Ha áttérek WebDav-ra akkor milyen szintű kompatibilitási problémákra számítsak? (Azt tudom hogy logon script nem lehet webdav meghajtón, de erre nincs is szükségem, nincs domain controller a cégnél.)

Ja és bocsánat ha rossz kategóriába írtam, nem találtam jobbat.

Köszönöm!

Hozzászólások

Ceph install tutorial-t olvasva rájöttem hogy az nem erre való. :-) Van olyan DFS ami 2 gépen is működik? Az se baj ha nincs sharding.

Nem biztos, hogy jól értem a problémát, de drbd+ocfs?

Esetleg glusterfs...

A DAV-ot viszont nem ajánlom SMB helyére, egész más pályán játszanak, és - leginkább a Windows-os webdav klienssel - sok-sok szívás tud vele lenni.

Mi a baj a Sambaval, mit értesz azon, hogy eljárt felette az idő?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Az a baj vele, hogy a legutóbbi Windows 10 frissítés óta az SMB1-et nem szereti, a Samba-ban meg nincs WSD támogatás, és a közeli jövőben nem is lesz. Itt van erről egy cikk: https://hup.hu/node/163555

Ha működne az SMB1 protokoll bekapcsolása Win10-en, akkor esetleg még lehetne is használni. De már akkor is alapvető probléma ezzel, hogy minden egyes Windows klienst kézzel kellene konfigurálni, feltételezhetően minden egyes Win10 frissítés után, és ennek az lenne az eredménye hogy folyamatosan konfigurálgatni kellene a gépeket. Ezt nagyon nem szeretném.

Ráadásul az SMB1 bekapcsolás nem is működik rendesen. Tegnap egy gépen egyik napról a másikra eltűntek a megosztások, és órák alatt nem sikerült újracsatlakoztatni őket. Föltettem az összes Windows frissítést, frissítettem a Samba-t és a BSD-t, és átnéztem minden létező leírást a neten a hasonló problémákról, de hiába. Azon a gépen sehogy nem megy. (Érdekes módon samba frissítés óta a többi gépen se szóval most még sürgősebb lett a dolog.)

Szóval ezek után beállítottam Samba-t úgy hogy SMB2 + SMB3 legyen, és sikerült beüzemelnem ezt is: https://github.com/christgau/wsdd.git - és most már ki lehet tallózni a samba szervert, de a megosztások mégse látszódnak.

Összefoglalva:

* Win 10 -nek SMB3 és WSD kell amit a Samba nem támogat és nem is fog
* A kiegészítő megoldások (mint ez a wsdd projekt) nekem nem működött
* Az SMB1 se működik, de ha működne akkor is folyamatos szívás lenne vele

Elkezdtem kutatni, hogy mit használhatnék helyette. Úgy tűnt, hogy a WebDAV nagyszerűen működik ilyen célra. Sokkal szabványosabb mint az (eleve rosszul induló) SMB protokoll amit az évek során tízszer átírtak.

De ha azt mondod hogy a Windows-os WebDAV kliens is problémás, akkor lassan itt az ideje hogy bepánikoljak. Ennek még ma délelőtt működnie kellene. :-o

Nem kell azt állítgatni.. SMB1-et kell elfelejteni már végre és ennyi. Fut samba szerverem nem egy helyen, win10/win7 -es kliensekkel felosztva. Mappelt network drive-okkal.

Soha nem volt olyan gondom, hogy frissítés után eltűnt volna bármelyik samba csatolt meghajtóm bármelyik gépről is. Soha.

Ha a kapcsolódások nem mennek a samba szerverhez, akkor ott bizony valami a samba szerver oldalán van elállítva.

+1.

Ráadásul rövid távon is rengeteg önszopatástól meg tud menteni, ha van egy AD domain, ha már ingyen lehet (oks, ajánlott a file kiszolgálón kívül egy másik szerver egy Samba telepítéssel, de egy kenyérpirítón is elfut).

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Nekem se volt vele gondom évekig. Aztán egyszer csak az egyik gépre jött egy Win frissítés, és hirtelen nem látta a megosztásokat. És utána nem tudtam újra csatlakozni se. Elhiszem hogy itt mindenki nagyon okos, és bizonyára sokkal jobban és ügyesebben konfigurálja a samba-t. Azt is elhiszem hogy én csináltam rosszul mindent, meg azt is hogy 5 perc alatt rajtam kívül bárki megoldotta volna ezt a csatlakozási problémát. Most leírhatnám hogy milyen hibaüzenetet kaptam, meg azt is hogy miket próbáltam végig hogy megjavítsam. Lehet hogy meg is fogom tenni, de ez nem most lesz. Azért, mert ez nem egy Samba topic, hanem egy "milyen DFS-t használjak" topic. (Meg azért is, mert egy nap szerencsétlenkedés után se sikerült megcsinálnom. Biztos én vagyok a hülye, de most akkor se fogok vele foglalkozni, mert nem és kész.)

Kérek szépen értelmes hozzászólásokat az eredeti kérdéshez!

* Melyik az a DFS ami két gépen is viszonylag könnyen beállítható?
* Ha van round robin akkor a WebDav-os windows-os mappelt meghajtó képes azt használni?

Szia! Semmi baj. Én kérek elnézést. Elég ingerült vagyok. Hülyének érzem magamat, és úgy érzem hogy egy napon keresztül hiába dolgoztam. :-(

Annyira belefáradtam ebbe a samba dologba, hogy úgy döntöttem kipróbálok valami mást. Lehet hogy közös erővel és segítséggel meg tudnám javítani, de már nem is akarom.

Az alapvető probléma nem a discovery hiánya volt, hanem egy tök másik hiba ami miatt nem lehetett csatlakoztatni. A WSD-t csak úgy odamondtam pluszban, mert irritáló dolog volt látni, hogy a Samba nem tudja, és nem is tervezik hogy tudni fogja.

A \\servernev\share sehogy nem működött. DNS rendben, lmhosts-ot is beírtam, engedélyeztem az SMB1-et is, próbáltam user hozzáadásával samba-ban és anélkül is és még 100 másik dolgot. Nem fogom őket felsorolni. Majd ha újra kedvet érzek a samba konfigurálásához, akkor nyitok egy új topicot. De az nem mostanában lesz.

Update: gyorsan föltettem az apache + webdav-ot és 15 perc múlva már simán működött, és egyelőre nem látok problémát. Bár az igaz hogy authentikáció még nincs, és https se (csak LAN-on használják) de ezeket hozzáadom később. Lefejeztek volna ha nem teszem működőképessé egy órán belül.

Akkor most a következő kérdés, hogy az authentikációt hogy oldjam meg - feltéve hogy tényleg két WebDav szerver és DFS lesz. Láttam egy mod_radius modult ( https://github.com/FreeRADIUS/mod_auth_radius ), használt már valaki ilyet?

(Igen, tudom hogy ha a router tönkremegy akkor ez megint single point of failure, de ha a router tönkremegy akkor úgyse úszom meg a személyes kiszállást...)

Apache + WebDAV-val én nem gondolkodnék aktív-aktív megoldásban, nem tudom, mennyire lesz stabil a lockdb párhuzamos írással (ha tippelnem kéne, nem lesz az).

Arra figyelj, hogy mielőtt auth-ot akarsz csinálni, mindenképp legyen HTTPS alatta olyan certtel, amit gondolkodás nélkül megeszik a kliens Windows, különben csak mindenféle random hibakódokat fogsz kapni (basic authot csak HTTPS felett hajlandó csinálni, az spnego meg kb. kiesik, ha nincs AD-d hozzá)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Köszönöm :-)

Akkor tehát olyan DFS-t keresünk, ami támogatja a lock-olást. Létezik ilyen?

Ha ez nem létezik, akkor esetleg azt is el tudom képzelni, hogy a router-be írok egy script-et ami észreveszi ha az egyik szerver elérhetetlenné válik, és ha ez megtörténik akkor update-eli a DNS-t a másik szerver címére. Ezzel a lock-olás dolog megoldódik, és a 100% redundancia is.

Kivéve persze a router-t, de ha az elromlik akkor úgyis ki kell mennem mert akkor megáll az élet. (És akkor még mindig csak egy restore kell a router mentéséből ami 10 perc alatt megvan.)

Az ocfs tudja, emiatt az írás, törlés kicsit időigényes, megbeszélik egymást között, hogy ki fogja a fájlt.

Keepalived, corosync ilyen dolgokkal szokták megoldani a haver figyelést.

Erről az egész témáról van linuxakademia-s oktatóanyag a weboldalukon. 9700 Ft körül van, annyit talán meg is ér a dolog, hogy ne szívd végig.

Akkor tehát olyan DFS-t keresünk, ami támogatja a lock-olást. Létezik ilyen?

Létezik, a gond az, hogy az Apache egy külön adatbázisban tartja nyilván a lockokat, nem pl. POSIX lockokkal vagy fájl-szintű lock fájlokkal (ezeket ugye szinkronizálná az FS). És abban nem vagyok biztos, hogy az Apache jó néven venné, ha párhuzamosan két gép próbálná írni ugyanazt a lockdb-t. (azt meg a kliensek nem vennék jó néven, ha nem lenne szinkronban a zárolási állapot a két kiszolgáló között)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Csak ehhez a részhez hozzászólva. Ne akarj DNS update alapján failovert. Ha jól értem egy hálózatban vagytok arra egy VRRP egy cluster IP címmel sokkal jobb. Linux alatt a keepalived tud VRRP-t, ahogy más is ajánlotta már. Nagyon egyszerű beállítani, de ha kell egy példa konfig azt is tudok küldeni.

> Arra figyelj, hogy mielőtt auth-ot akarsz csinálni, mindenképp legyen HTTPS alatta olyan certtel, amit gondolkodás nélkül megeszik a kliens Windows, különben csak mindenféle random hibakódokat fogsz kapni (basic authot csak HTTPS felett hajlandó csinálni, az spnego meg kb. kiesik, ha nincs AD-d hozzá)

Letsencrypt az ilyen, vagy azt nem eszi meg?

Szerkesztve: 2020. 04. 01., sze - 02:16

Szia!

Elosztott fájlrendszerek cluster alapúak, azaz min. 3 szerver kell hozzá.

Backend (DFS)
-beegfs + ZFS
-xtreemefs

Frontend / Kliens oldal:
-Windows beépített Webdav kliens - max. fájlméret 4GB.
-Windows SSHFS: WinFsp + SSHFS-Win

Windows programoknak NTFS réteg emuláció szükséges (lock,acess,stb.), ezáltal sok lehetőség nem marad, tehát marad az Samba.

Másik megközelítés, hogy máshogy érjük el a HA-t.
A.,
Három fizikai szerveren(node1,node2,node3) fut valamilyen virtualizációs környezet, aminek van közös Tároló-ja (storage), van egy virtuális gép (FreeNAS) ami az egyik node-on fut, ha ez a node leáll, akkora másik node-n újra elindúl a virtuális gép (FreeNAS).
Valamekkora kiesés lesz, de adat nem fog elveszni.

B.,
Három fizikai szerveren(node1,node2,node3) fut valamilyen Virtualizációs környezet, megveszel 2db Windows Server-t, beállítod a "Failover-Cluster"-t - tárolónak meg emulálsz "Storage Spaces"-t vagy ISCSI a (node1,node2,node3) -n.

Egyszerűen az Windows SMB nem erre lett tervezve, egy zárt "csökevény".

Szerkesztve: 2020. 05. 15., p - 17:37

Eltelt egy hónap, mondom a tapasztalatokat:

* Sima http -vel basic auth-tal vagy anélkül, minden jól működik. Kivéve, hogy néha az MS Office lock-ol egy file-t és úgyhagyja. Akkor nem segít semmi csak az apache restart.

* Ha kell egy minimális biztonság, akkor a DAV mehet a kukába. Hiába az érvényes Let'sEncrypt-es cert. A legtöbb program ezzel is jól megy. Kivéve MS Office, mert az nem hajlandó. (Ugye miért pont az működne?)

A végén mégiscsak visszatértem samba-ra. Mert rájöttem, hogy mi volt a baj. Mindent jól csináltam. A wssd, SMB protokol beállítás stb. minden jó volt. Nincs szükség nem biztonságos protokollra, nem kell group policy módosítás, és minden rendben van. Egyetlen egy dolog hiányzott:

    ports = 445

Az alapértelmezett 139-es porton nem működött egyik win10-es géppel se. Ami még furcsább, hogy egy bizonyos windows frissítés utántól nem működött, és azóta se találtam arról semmi infót, hogy ez változott volna. Főleg nem mostanában.

Ennek ellenére így van. Év elején még ment 139-en (ugyan azzal a protokollal), de most már csak 445-ön megy.

Gondoltam leírom, hátha valakinek lesz hasonló baja.