Piszki Lab

Analiza przypadku w języku przodków…

Bezpieczny serwer plikowy oparty o Samba, CTDB, CephFS i OpenLDAP

| 0 comments

Celem dzisiejszego ćwiczenia będzie uruchomienie bezpiecznego, czyli zapewniającego pełne HA, klastra Samby za pomocą którego będziemy serwować pliki bezpośrednio z CephFS oraz autoryzować użytkowników na poziomie OpenLDAP. Najbliższym odpowiednikiem tej konfiguracji jest usługa Failover Cluster + DFS dostępna w Microsoft Windows Server 2012+. Konfigurację Ceph oraz OpenLDAP znajdziecie w podlinkowanych artykułach, tutaj skupimy się głównie na CTDB i Samba. Clustered Trivial Data Base, bo tak rozwija się ten skrót, zapewnia spójność sesji użytkowników pomiędzy wieloma węzłami. Nadzoruje także pracę samej samby. W opisywanej konfiguracji zostanie użyty moduł VFS samba-vfs-ceph (Samba Gateway for CephFS), moduł ten pozwala sambie pracować poprawnie (natywnie) z Ceph. Za pomocą tego modułu Samba zrzuca na CephFS wszystkie operacje plikowe (otwarcie, zablokowanie, zamknięcie itp.). Aby zapewnić spójność z ostatnimi konfiguracjami, użytkownicy będą brani z OpenLDAP (będzie tam też przechowywana cała konfiguracja Samby). Dzięki takiemu podejściu zyskamy spójną, redundantną konfigurację, która płynnie połączy wiele komponentów. Ze względu na użycie najnowszych wersji, które nie są dostępne w CentOS 7 ani Ubuntu 18, cała konfiguracja zostanie przeprowadzona w systemie Fedora Server 29 (ale myślę, że bez problemu postawimy ja na CentOS 8).

smb5

Przygotowanie Fedora 29 (CentOS 8):
yum install mc wget curl numactl git tuned mailx yum-utils deltarpm nano bash-completion net-tools bind-utils lsof screen bmon ntp rsync nmap socat ntpdate dconf authconfig nss-pam-ldapd pam_krb5 krb5-workstation openldap-clients cyrus-sasl-gssapi langpacks-pl oddjob-mkhomedir openldap-clients samba-vfs-cephfs ctdb samba-winbind-clients smbldap-tools ceph-common samba-client

Użyjemy dwóch węzłów Samby, całość będzie się łączyć do serwerów HDC1 i HDC2 opisanych w poprzednim artykule. Serwery otrzymały nazwy:

smb1.hdfs.lab – 192.168.30.51

smb2.hdfs.lab – 192.168.30.51

Oraz dodatkowo, na potrzeby klastra, został przygotowany jeden, publiczny adres smb.hdfs.lab – 192.168.30.50 poprzez który będą udostępniane zasoby Samby. Każdy z serwerów (w moim przypadku wirtualne maszyny) mają po dwa interfejsy sieciowe, pierwszy pełni rolę MGMT a drugi PUBLIC. System serwerów SMB musi być w pełni zintegrowany z OpenLDAP tak jak było to pokazane w tym artykule (użytkownik LDAP jest jednocześnie użytkownikiem POSIX i SAMBA). Serwer OpenLDAP musi mieć dodatkowo wgrany schemat SAMBA, plik /usr/share/doc/samba/LDAP/samba.ldif (dostępny na Fedora 29) należy załadować (z poziomu serwera LDAP) poleceniem ldapadd -Y EXTERNAL -H ldapi:/// -f samba.ldif. Na obydwu węzłach pliki konfiguracyjne muszą być takie same, dodatkowo musi być zamontowany udział CephFS który zapewni obsługę pliku lock dla usługi CTDB (tutaj: /data/ctdb/lock/ctdb.lck). Czyli nie tylko wykorzystujemy CephFS jako udostępniany po CIFS udział sieciowy ale też jako zasób klastrowy pod plik lock CTDB (posiadanie takiego sklastrowanego udziału jest wymagane do poprawnej przacy CTDB). Jak widzicie, całe środowisko jest ściśle ze sobą zintegrowane. Na obydwu węzłach klastra konfigurujemy sambę w identyczny sposób, plik sbm.conf:

smb1

Jak widzicie, uprawnienia trzymane są w OpenLDAP, jest to dość uproszczona konfiguracja, wymaga jedynie, aby użytkownik zautoryzował się w OpenLDAP i uzyska on automatycznie uprawnienia do zapisu i odczytu. Samba sięga wprost do pliku ceph.conf zawierającego informację gdzie są monitory Ceph, wprost jest też podany użytkownik którym Samba podłącza się do Ceph (samba.gw). W moim przypadku klaster Ceph to zupełnie inne maszyny niż te obsługujące Sambę.

smb2

Użytkownika i hasło generujemy poleceniem: ceph auth get-or-create client.samba.gw mon ‘allow r’ osd ‘allow *’ mds ‘allow *’ -o ceph.client.samba.gw.keyring

Przejdźmy teraz do CTDB, usługa ta działa na bardzo podobnej zasadzie co KeepaliveD, wykorzystuje protokół VRRP do sprawdzania czy dany węzeł żyje i odpowiada. Na każdym węźle konfiguracja różni się tylko adresem IP węzła. Plik /etc/ctdb/ctdb.conf :

smb3

W pliku /etc/ctdb/nodes przechowujemy IP węzłów klastra a w pliku /etc/ctdb/public_addresses podajemy jeden lub wiele adresów publicznych oraz interfejs na którym usługa będzie nasłuchiwać.

smb4

Cały klaster może być tak skonfigurowany, że będziemy mieli wiele IP publicznych, i każdy z nich może nasłuchiwać w innym węźle, całość może być np. skonfigurowana w jeden rekord DNS działający jako round robin co zwiększy dostępność udziału. W moim przypadku mamy dwa węzły i jeden publiczny IP, typowy failover. Należy pamiętać, że całością steruje usługa CTDB, to ona uruchamia i stopuje Sambę. Jak to działa? W przypadku takiej konfiguracji Samba działa jak typowe proxy, autoryzuje użytkownika i całość operacji dyskowych kieruje do CephFS. Oznacza to, że transfer jaki osiągniemy jest równy wydajności sieci publicznej obsługującej Ceph i karty sieciowej w maszynie obsługującej CTDB. W naszej konfiguracji możemy zastosować pewną modyfikację, mamy lokalnie zamontowany zasób CephFS, możemy go też z tego poziomu wyeksportować.

smb6

Dołożenie takiego kawałka do konfiguracji smb.conf spowoduje, że wyeksportujemy standardowy udział lokalny (z uprawnieniami jak wyżej). Różnica w działaniu jest taka, że wszelkie operacje dyskowe bierze na siebie ceph-client i dodatkowo mamy do czynienia z lokalnym buforem dyskowym w RAM. Z jednej strony jest szybciej, RAM jest wykorzystywany jako cache zapisu z drugiej trochę mniej bezpiecznie, jeśli maszyna ulegnie awarii z danymi w cache, będziemy mieli straty w danych. Podsumowując, wyżej opisana konfiguracja pozwala w sposób całkowicie natywny i zintegrowany wystawić jako udział CIFS zasób CephFS w sposób bezpieczny i wysoko dostępny.

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.