PL-Grid-KFS-v1.6

Transkrypt

PL-Grid-KFS-v1.6

SYSTEM
KEYFS
D O K U M E N T A C J A
M O D U Ł U
Nazwa pliku dokumentu: PL-Grid-KFS-v1.6-WCSS-dokumentacja-systemukeyFS.odt
Zadanie:
4.5.1
Partnerzy:
WCSS
Partner koordynujący:
WCSS
Wersja dokumentu:
1.6
Typ dokumentu:
Publiczny
Streszczenie: Dokument prezentuje założenia, funkcjonalność, instalacje
uwierzytelniania KeyFS.
Polska Infrastruktura Informatycznego Wspomagania Nauki w Europejskiej
Przestrzeni Badawczej – PL-Grid
modułu
Page 1 of 16
Historia zmian dokumentu
Wersja
Data
Opis zmian
Autorzy
0.1
20.07.2010
Szkic dokumentu.
Bartłomiej Balcerek
0.7
24.03.2011
Sekcja instalacja, poprawki
0.8
25.03.2011
Franciszek Klajn
1.0
28.03.2011
Podsekcja konfiguracji
poinstalacyjnej
Uzupełnienia, poprawki
1.1
13.05.2011
1.2
17.06.2011
Dodanie opisu konfiguracji
repliki LDAP, poprawki
Poprawienie konfiguracji LDAP
1.3
11.07.2011
Mariusz Uchroński
1.5
04.01.2012
1.6
12.01.2012
Dopisanie opisu struktury pliku
konfiguracyjnego i nowych
opcji związanych z listami CRL.
Dostosowanie do nowego
schematu LDAP
Aktualizacja, poprawki
Page 2 of 16
Spis treści
1. WPROWADZENIE............................................................................................................................................4
1.1. CEL DOKUMENTU..............................................................................................................................................4
1.2. REFERENCJE.....................................................................................................................................................4
1.3. TERMINOLOGIA................................................................................................................................................4
2. ZAŁOŻENIA......................................................................................................................................................5
2.1. BAZA DANYCH UŻYTKOWNIKÓW PL-GRID...........................................................................................................5
2.2. DOSTĘP DO KONSOLI GRIDU................................................................................................................................5
3. CEL ZASTOSOWANIA SYSTEMU KEYFS W PL-GRID..........................................................................6
4. INTEGRACJA Z NARZĘDZIAMI GRIDOWYMI I FUNKCJONALNOŚĆ.............................................7
4.1. IMPLEMENTACJA...............................................................................................................................................7
4.2. FUNKCJONALNOŚĆ............................................................................................................................................7
4.2.1. Wsparcie dla logowania SSH (opcjonalne)........................................................................................7
4.2.2. Wsparcie dla generowania certyfikatów proxy...................................................................................8
4.3. ARCHITEKTURA I ZASTOSOWANE TECHNOLOGIE ....................................................................................................8
5. WSPÓŁDZIAŁANIE Z INNYMI KOMPONENTAMI GRIDU.................................................................10
6. KONFIGURACJA I INSTALACJA..............................................................................................................11
6.1. STRUKTURA PLIKU KONFIGURACYJNEGO..............................................................................................................11
6.2. KONFIGURACJA LOKALNEJ REPLIKI LDAP.........................................................................................................12
6.3. INSTALACJA PACZKI, KONFIGURACJA I URUCHOMIENIE..........................................................................................13
6.4. WERYFIKACJA INSTALACJI................................................................................................................................13
6.5. KONFIGURACJA SYSTEMU.................................................................................................................................14
6.6. KONFIGURACJA MONITORINGU NAGIOS...............................................................................................................14
7. OCENA WYDAJNOŚCI I SPRAWNOŚCI...................................................................................................15
8. MOŻLIWE DROGI ROZWOJU APLIKACJI ............................................................................................16
Page 3 of 16
1. WPROWADZENIE
1.1. CEL DOKUMENTU
Dokument niniejszy ma na celu przedstawienie założeń systemu keyFS oraz jego funkcjonalności
a także stanowi dokumentacje pomocną przy jego instalacji i rozwoju.
1.2. REFERENCJE
R1
R2
www.openldap.org
http://fuse.sourceforge.net/
Tabela 1: Tabela referencji
1.3. TERMINOLOGIA
Akronimy
CA
Certification Authority
UI
User Interface
FUSE
Filesystem in USErspace
LDAP
Lightweight Directory Access Protocol
Page 4 of 16
2. ZAŁOŻENIA
2.1. BAZA DANYCH UŻYTKOWNIKÓW PL-GRID
W projekcie PL-Grid konta wszystkich użytkowników przechowywane są w bazie
katalogowej LDAP. Jako implementacja protokołu LDAP została wybrana aplikacja OpenLDAP.
W rekordzie każdego użytkownika przechowywane są także jego poświadczenia, w postaci
certyfikatu klucza publicznego X509 oraz odpowiadającemu mu klucza prywatnego, zaszyfrowanego
silnym algorytmem kryptograficznym. Należy zaznaczyć, że w bazie LDAP, jako zewnętrznej
składnicy danych mogą być przechowywane tylko kluczy prywatne użytkowników certyfikowane
przez centrum certyfikacji (ang. CA), którego polityka zezwala na eksportowanie tych kluczy poza
stację roboczą użytkownika. Takim centrum certyfikacji w PL-Grid jest SimpleCA.
2.2. DOSTĘP DO KONSOLI GRIDU
Dostęp użytkownika do konsoli gridu możliwy jest dzięki wydzielonym do tego celu
maszynom, tzw. UI (ang. User Interface). UI jest serwerem sieciowym, do którego dostęp możliwy
jest dzięki protokołowi SSH, który jednocześnie ma zainstalowany i skonfigurowany middleware
gridowy. W ten sposób maszyna ta stanowi integralną część gridu. W takim schemacie użytkownik
nawiązuje sesje z UI używając hasła, po zalogowaniu się zaś ma możliwość wygenerowania
poświadczeń gridowych (tzw. certyfikatu proxy) i następnie komunikowania się z innymi serwerami
gridowymi. Niniejsze rozwiązanie powoduje, że procedura dostępu użytkownika do konsoli gridu jest
niewygodna. Jej scenariusz opisany jest poniżej, dla pierwszego logowania przedstawiony jest
poniżej:
•
•
•
•
•
Pobranie z portalu paczki PKCS12 z kluczem i certyfikatem
Skopiowanie na UI paczki PKCS12
Wypakowanie klucza prywatnego i certyfikatu
Zalogowanie się na UI używając hasła
Wygenerowanie certyfikatu proxy używając hasła
Powyższa procedura powinna zostać powtórzona dla każdego UI z którego użytkownik będzie miał
zamiar korzystać.
Page 5 of 16
3. CEL ZASTOSOWANIA SYSTEMU KEYFS W PL-GRID
Aplikacja keyFS może w infrastrukturze spełniać dwie funkcje. Po pierwsze, keyFS
zainstalowany na wszystkich maszynach UI (ang. User Interface) może dostarczać użytkownikowi
gridowych poświadczeń (klucz prywatny i certyfikat użytkownika) od razu po zarejestrowaniu się
użytkownika w portalu i wygenerowaniu certyfikatu Simple CA. W takim przypadku nowy
użytkownik nie musi wykonywać całej sekwencji czynności związanej z pobraniem paczki PKCS12
z portalu (skopiowanie PKCS12 jej na wybrane UI, konwersja na format akceptowany przez
narzędzia gridowe, zapewnienie odpowiednich praw dostępu, itp.). KeyFS dostarczy plików
z certyfikatem i kluczem prywatnym użytkownikowi na wszystkich UI, w chwilę po rejestracji konta
w portalu.
Druga funkcja keyFS, opcjonalną do wykorzystania przez „site”, dotyczy kontroli nad ważnością
kont szkoleniowych, zakładanych na UI. Obecnie konta na UI nie są związane z gridowymi
mechanizmami kontroli dostępu, np. po wygaśnięciu lub też odwołaniu gridowego certyfikatu
użytkownika dysponuje on ciągle dostępem do konta na UI. Dzięki współdziałaniu keyFS
z OpenSSH możliwe jest ograniczenie dostępu do takiego konta dla użytkowników z ważnym
certyfikatem gridowym, pod warunkiem, że jedyną metodą dostępu do konta na UI będzie użycie
klucza publicznego użytkownika, a nie hasła, którego użycie powinno być w takim scenariuszu
zablokowane (dotyczy użytkowników szkoleniowych).
Page 6 of 16
4. INTEGRACJA Z NARZĘDZIAMI GRIDOWYMI I FUNKCJONALNOŚĆ
4.1. IMPLEMENTACJA
KeyFS udostępnia wirtualny system plików. Pliki tego systemu odzwierciedlają zawartość
wybranych rekordów w bazie LDAP użytkowników PL-Grid. KeyFS stanowi zatem warstwę
pośredniczącą pomiędzy bazą LDAP a aplikacjami związanymi z uwierzytelnianiem.
KeyFS realizuje swoje funkcje w systemie PL-Grid dzięki integracji z narzędziami gridowymi gridproxy-init, voms-proxy-init oraz demem OpenSSH. Integracja ta polega na wskazaniu w konfiguracji
ww. narzędzi odpowiednich plików keyFS jako ich konfiguracji. Poniżej zaprezentowane jest
przykładowe drzewo plików udostępniane przez keyFS (montowane w katalogu /mnt/keyfs).
Rys 1. Przykład wirtualnego systemu plików udostępnianego przez keyFS
Główną zaletą implementacji interfejsu pomiędzy aplikacjami związanymi z uwierzytelnianiem
a bazą użytkowników w postaci systemu plików jest brak konieczności modyfikowania kodów
serwerów dostępowych (OpenSSH, GridFTP). Takie rozwiązanie ma znaczenie dla ogólnego
bezpieczeństwa serwerów dostępowych i narzędzi, ich stabilności oraz pozwoli na łatwiejsze
utrzymywanie ich w najnowszych dostępnych wersjach.
4.2. FUNKCJONALNOŚĆ
4.2.1. Wsparcie dla logowania SSH (opcjonalne)
Page 7 of 16
Jedną z bezhasłowych metod logowania, wspieranych przez serwer OpenSSH jest dostęp
dzięki parom asymetrycznych kluczy kryptograficznych RSA/DSA. Posiadacz klucza prywatnego
może przedstawić się nim serwerowi, który zna odpowiadający mu klucz publiczny i w ten sposób
uzyskać dostęp. Klucz publiczny pobierany jest z pliku dyskowego, zlokalizowanego odpowiednio do
loginu wprowadzonego przez użytkownika. Zadaniem Modułu KeyFS jest zasymulowanie takiego
pliku dyskowego na podstawie informacji pobranych z bazy LDAP. Moduł łączy się z bazą
użytkowników, dekoduje pobrany certyfikat X509 użytkownika i tworzy w ścieżce <mount
point>/users/<nazwa uzytkownika>/.ssh/authorized_keys plik z kluczem publicznym użytkownika
w formacie OpenSSH.
By zapewnić integrację z serwerem OpenSSH konfiguracja tego ostatniego powinna zostać
uzupełniona o następujący wpis:
AuthorizedKeysFile
<mount point>/users/%u/.ssh/authorized_keys
Ze względów bezpieczeństwa, na bazie pobranego certyfikatu użytkownika moduł keyFS tworzy
pełną ścieżkę certyfikacyjną, przy wykorzystaniu certyfikatów podmiotów nadrzędnych pobranych
z tej samej bazy. Całą ścieżka certyfikacji będzie weryfikowana przed udostępnieniem wirtualnego
pliku zawierającego klucz. Dodatkowo na etapie udostępniania klucza publicznego keyFS pobiera
z atrybutów certyfikatu CA adres listy CRL, którą stara się ściągnąć i uwzględnić przy weryfikacji
certyfikatu użytkownika. Możliwe jest także pobranie plików zawierających CRL z lokalnego
katalogu dyskowego, jeśli znalazły się tam one np. dzięki działaniu skryptu „fetchcrl”. Dodatkowo za
pośrednictwem odpowiedniego pola w pliku konfiguracyjnym (crl_check) można sterować
poziomem weryfikacji certyfikatu użytkownika. Możliwe jest wyłączenie weryfikacji certyfikatu
użytkownika z listą CRL, weryfikacja certyfikatu z odpowiadającą mu listą CRL lub weryfikacja
z listami CRL dla całego łańcucha certyfikacji. Ze względów wydajnościowych listy CRL są
przechowywane w pamięci i okresowo odświeżane (domyślnie co 4 godziny). Jeśli z jakiegoś powodu
ścieżka certyfikacji nie może zostać zweryfikowana poprawnie lub też wystąpił inny błąd,
zawartością pliku <mount point>/users/%u/.ssh/authorized_keys jest napis: „Cannot get user key
from LDAP or cannot validate certificate, please check logs!”
4.2.2. Wsparcie dla generowania certyfikatów proxy
Narzędzia gridowe służące do generowania certyfikatów proxy wymagają podania lokalizacji
klucza prywatnego użytkownika oraz jego certyfikatu. Domyślna ścieżka poszukiwania tych plików
to odpowiednio $HOME/.globus/userkey.pem oraz $HOME/.globus/usercert.pem. keyFS przy
uruchomieniu odczytuje z bazy LDAP rekordy wszystkich użytkowników i w przypadku tych, które
zawierają certyfikaty i klucze prywatne tworzy odpowiadające im katalogi zlokalizowane w: <mount
point>/users/<nazwa uzytkownika>/.globus. Dzięki wskazaniu tej lokalizacji w parametrach narzędzi
grid-proxy-init lub voms-proxy-init, bądź w zmiennych środowiskowych X509_USER_KEY
i X509_USER_CERT możliwe jest generowanie certyfikatów proxy na bazie danych pochodzących
oryginalnie z bazy LDAP. Certyfikat i klucz publiczny nie są weryfikowane przez keyFS
w rozumieniu ważności, ponieważ taka weryfikacja przeprowadzana zostanie na etapie użycia przez
oprogramowanie Globus.
4.3. ARCHITEKTURA I ZASTOSOWANE TECHNOLOGIE
Do implementacji keyFS wybrany został system plików (biblioteka) FUSE (ang. Filesystem
Page 8 of 16
in USErspace). FUSE umożliwia tworzenie i używanie systemów plików, których kod nie musi być
ładowany do jądra systemu operacyjnego. Takie podejście zapewnia min. znacznie większą
przenośność takiego rozwiązania pomiędzy platformami sprzętowymi, programowymi oraz wersjami
jąder systemowych a także większe bezpieczeństwo i stabilność całego systemu.
Moduł keyFS zaimplementowany został w języku C. Dwie najbardziej istotne, zastosowane biblioteki
to „libfuse” oraz „libldap”. Moduł można podzielić na trzy główne obszary, ze względu na
wykonywane funkcje:
- Dostęp do bazy LDAP – wykorzystano standardowe API OpenLDAP, w tym funkcje
przeszukiwania katalogu, sortowania rekordów oraz zapewniania wysokiej dostępności.
- Funkcje kryptograficzne – realizowane przy użyciu biblioteki OpenSSL i funkcji OpenSSH,
w tym funkcje konwersji formatów certyfikatów X509, funkcje konwersji kluczy RSA/DSA,
funkcje weryfikacji łańcucha certyfikacji.
- Funkcje systemu plików – odpowiadające za tworzenie wirtualnego systemu plików.
Architekturę modułu przedstawia schematycznie rysunek 2.
Rys 2. Przykład wirtualnego systemu plików udostępnianego przez KeyFS
Page 9 of 16
5. WSPÓŁDZIAŁANIE Z INNYMI KOMPONENTAMI GRIDU
Umiejscowiony w WCSS serwer EJBCA udostępnia zdalnie API Web Service, w tym
metodę
służącą do podpisania żądania certyfikacji, zwracającą podpisany certyfikat (po
uwierzytelnieniu klienta).
1. Użytkownik wypełnia wniosek o uzyskanie konta. Po akceptacji wniosku przez operatora
portal PL-Grid generuje klucz prywatny użytkownika oraz CSR (Certificate Signing
Request). CSR jest tworzony na podstawie wprowadzonych przez użytkownika danych.
2. Portal wysyła CSR, poprzez interfejs Web Service, do CA, zlecając podpisanie wniosku.
3. Portal otrzymuje podpisany certyfikat od CA. Klucz prywatny użytkownika jest umieszczany
w kontenerze PKCS #8, zaszyfrowanym hasłem podanym przez użytkownika w formularzu
rejestracyjnym. Do zaszyfrowania klucza używany jest algorytm AES-256-CBC (przykład
PKCS #8 w załączniku 1).
4. Zaszyfrowany klucz prywatny oraz podpisany certyfikat umieszczane są w bazie LDAP w,
rekordzie użytkownika.
5. Na tym etapie musimy zapewnić, żeby klucz użytkownika oraz jego certyfikat znajdujące się
w bazie LDAP zostały użyte to generowania certyfikatu proxy. Mechanizm zapewniający to
wymaganie opisany został w punkcie 6.3
Rys 3. Przykład wirtualnego systemu plików udostępnianego przez keyFS
Page 10 of 16
6. KONFIGURACJA I INSTALACJA
W celu skorzystania z funkcjonalności dostarczanych przez
uruchomieniem, należy przeprowadzić następujące czynności:
•
•
•
•
system
keyFS,
przed
jego
konfiguracja lokalnej repliki LDAP,
instalacja systemu keyFS z paczki RPM,
modyfikacja domyślnego pliku konfiguracyjnego keyFS,
konfiguracja systemu.
Paczka instalacyjna systemu keyFS zawiera skrypt (do_keyfs_test.sh) pozwalający na weryfikację
poprawności utworzonego wirtualnego systemu plików.
6.1. STRUKTURA PLIKU KONFIGURACYJNEGO
Poszczególne pola w pliki konfiguracyjnym systemu keyFS oznaczają:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
uri – adres bazy LDAP (lokalnej repliki),
binddn – login do lokalnej repliki bazy LDAP,
bindpw – hasło dla loginu określonego przez pole binddn,
ca_base – nazwa gałęzi z certyfikatami CA,
plgrid_user_base – nazwa gałęzi z użytkownikami PL-Grid,
crls – parametr mówiący, czy obecność list CRL jest konieczna do pozytywnej walidacji
certyfikatu użytkownika. Dla wartości required brak list CRL powoduje negatywną
walidację certyfikatu. Dla wartości optional certyfikat może zostać poprawnie
zwalidowany, nawet jeśli nie były dostępna odpowiadające mu listy CRL,
crl_source – źródło, z którego pobierane są listy CRL; pole to może przyjmować
wartości dir lub url, gdzie dir oznacza, że listy CRL są pobierane z lokalnego katalogu
dyskowego określonego przez pole crl_dir, wartość url oznacza, że listy CRL są
pobierane z sieci, z adresów zaszytych w certyfikatach CA i użytkowników,
crl_check – określa poziom weryfikacji certyfikatu użytkownika z listą CRL; może
przyjmować wartości: all – weryfikacja wszystkich certyfikatów w ścieżce certyfikacji z
listami CRL, last – weryfikacja certyfikatu użytkownika z odpowiadającą listą CRL, lub
none – brak weryfikacji certyfikatu użytkownika z listą CRL,
crl_reload – okres co który pobierane są nowe listy CRL w sekundach,
actasuser – nazwa użytkownika, dla którego uruchamiany jest keyFS,
actasgroup – nazwa grupy, dla której uruchamiany jest keyFS
ssh_key_options – opcje SSH dodawane do pliku authorized_keys,
keyfs_mode – tryb pracy systemu keyFS, dla pracy w środowisku PL-Grid pole to
powinno mieć wartość grid,
pidfile – plik z numerem PID dla procesu keyFS,
Page 11 of 16
6.2. KONFIGURACJA LOKALNEJ REPLIKI LDAP
KeyFS w lokalnej replice LDAP powinien mieć wyodrębnione konto. Należy je stworzyć, dopisując
do pliku slapd.conf następującą definicję bazy z jednym rekordem (rootdn):
database bdb
suffix "cn=keyFS"
rootdn "cn=keyFS"
rootpw <passphrase>
directory /var/lib/ldap/keyfs
access to dn.subtree="cn=keyFS"
by * none
Element „passphrase” do wpisania powyżej generujemy następująco:
slappasswd -h {SSHA} -s <wybrane_haslo_keyfs>
Należy także utworzyć katalog /var/lib/ldap/keyfs lub inny, z dostępem do zapisu
przez slapd.
Lokalna replika LDAP musi także zawierać odpowiednie prawa dostępu do danych. Poniżej
zaprezentowana jest właściwa konfiguracja – należy jedynie zadbać o zmianę atrybutów DN na
odpowiednie dla danego ośrodka. Ważna jest odpowiednia kolejność regułek, ze względu na
kolejność przetwarzania ich przez demona LDAP, która powinna być taka jak poniżej.
#Prawa do prywatnego atrybutu z haslem
access to dn.subtree="dc=plgrid,dc=pl" attrs="userPassword"
by * auth
by self write
by dn="cn=Manager,dc=wcss-test,dc=plgrid,dc=pl" write
#Prawa do certa i prywatnego klucza dla keyFS
access to dn.subtree="dc=plgrid,dc=pl"
attrs=plgridX509Certificate,plgridX509Key
by dn="cn=keyFS" read
#Prawa do pozostałych atrybutów dla dostępu anonimowego
access to dn.subtree="dc=plgrid,dc=pl"
by * read
#Zamknięcie reguł (opcjonalne)
access to *
by * none
Page 12 of 16
Po wprowadzeniu powyższych reguł należy upewnić się, że anonimowy dostęp do bazy nie
umożliwia odczytu atrybutów plgridX509Key oraz userPassword !
6.3. INSTALACJA PACZKI, KONFIGURACJA I URUCHOMIENIE
Paczkę RPM, przygotowaną dla systemu SCL/Centos 5.x instaluje się w standardowy sposób, np.
rpm -ivh plgrid-keyfs-<wersja>.x86_64.rpm
Po zainstalowaniu paczki, przed uruchomieniem aplikacji należy przygotować konfigurację:
Do pliku /etc/fuse.conf dopisujemy linijkę: user_allow_other.
Następnie należy wyedytować plik: /opt/plgrid/keyfs/etc/keyfs.conf i podać poprawny adres bazy
LDAP (lokalnej repliki), nazwy gałęzi z użytkownikami oraz certyfikatami CA, odpowiednie
poświadczenia dostępowe (login, hasło), poziom weryfikacji certyfikatu użytkownika z listą CRL,
oraz katalog z bieżącymi listami CRL np.:
uri ldap://ldap.wcss.wroc.pl
binddn
cn=keyFS
bindpw <wybrane_haslo_keyfs>
ca_base
ou=Certs,dc=<nazwa ośrodka>,dc=plgrid,dc=pl
plgrid_user_base ou=People,dc=WCSS,dc=plgrid,dc=pl
crls required
crl_source url
crl_check last
crl_reload 14400
Parametry połączenia SSL/TLS (w tym lokalizacja certyfikatów i kluczy) zostaną pobrane z pliku
/etc/ldap.conf. W ten sposób konfiguracja bezpiecznego połączenia będzie współdzielona z innymi
klientami LDAP, np. Name Service Switch. Inną lokalizację pliku z tą konfiguracją można wskazać
używając zmiennej środowiskowej LDAPCONF.
Uruchomienie keyFS wymaga wykonania polecenia:
/etc/init.d/keyfs start
6.4. WERYFIKACJA INSTALACJI
Po poprawnym uruchomieniu aplikacji keyFS powinien utworzyć wirtualny system plików
w katalogu /mnt/keyfs. Poprawność zawartości tego systemu plików można sprawdzić poprzez
Page 13 of 16
wykonanie polecenia::
/opt/plgrid/keyfs/bin/do_keyfs_test.sh
6.5. KONFIGURACJA SYSTEMU
Aby użytkownik mógł automatycznie korzystać z certyfikatu oraz klucza wystawianych przez keyFS
należy ustawić odpowiednio zmienne powłoki X509_USER_CERT i X509_USER_KEY. w tym celu
tworzone są pliki w katalogu /etc/profile.d (dla powłok bash oraz csh), które ustawiają odpowiednio
środowisko oraz tworzą alias creds. To ostatnie polecenie pozwala użytkownikowi już podczas pracy
wybrać, z których kluczy będzie korzystał – z lokalnych czy tych wystawianych przez LDAP.
6.6. KONFIGURACJA MONITORINGU NAGIOS
Usługa jest monitorowana w ramach monitoringu UI i ze strony administratora nie jest wymagana
żadna dodatkowa interwencja. Test sprawdza stan keyFS na podstawie analizy zawartości pliku
/mnt/keyfs/status.txt.
Page 14 of 16
7. OCENA WYDAJNOŚCI I SPRAWNOŚCI
Na wydajność modułu składają się takie elementy jak szybkość wymiany komunikatów
z bazą danych (w tym szerokość pasma sieciowego do serwera LDAP oraz wydajność sprzętu z bazą
danych), czas buforowania informacji pobieranych z LDAP oraz wydajność operacji
kryptograficznych. w celu zmierzenia wydajności przeprowadzony został szereg testów.
Poniżej (Rysunek 1) prezentowane są pomiary przeprowadzone dla następującej konfiguracji: serwer
KeyFS: Intel Core 2 Duo 2.66 GHz, serwer LDAP: Intel Itanium 2 2x 1,3 GHz, połączenie między
serwerami LAN o prędkości 100 Mb/s nieszyfrowane, keyFS uruchomiony w trybie jednowątkowym.
Jeden pomiar testowy polegał na wielokrotnym wykonywaniu jednoczesnych żądań odczytu zestawu
wszystkich plików udostępnianych przez KeyFS, w losowej kolejności.
Rys. 1 Wydajność modułu keyFS
Liczba operacji (odczytów wirtualnych plików) na sekundę waha się od 10 do 200 i zależy od
długości kolejki żądań. Wydajność modułu zaczyna silnie maleć dla kolejek żądań powyżej 100
elementów, co jest związane z właściwościami mechanizmu buforowania lokalnego danych
pobranych z LDAP. w tej konfiguracji dane takie są przechowywane lokalnie przez okres 5-ciu
sekund. Należy pamiętać, że pojedyncze żądania odczytów przedzielone interwałami dłuższymi niż 5
sekund będą realizowane z mniejszą wydajnością i w takich warunkach otrzymano czas realizacji
pojedynczej operacji na poziomie 0.1-0.3 s. w trakcie trwania testu moduł nie zużywał więcej niź 5
MB pamięci operacyjnej.
Page 15 of 16
8. MOŻLIWE DROGI ROZWOJU APLIKACJI
Wykorzystanie systemu plików jako interfejsu do komunikacji pomiędzy bazą użytkowników
i ich poświadczeń a aplikacjami daje bardzo szerokie możliwości integracji jeśli chodzi o zakres tych
aplikacji. Podstawowym ograniczeniem charakterystycznym dla takiego sposobu komunikacji jest
wymóg by dana aplikacja wczytywała konfigurację z plików dyskowych za każdym razem, kiedy
podejmuje akcję sterowaną taką konfiguracją, a nie tylko w chwili startu.
Page 16 of 16

PL-Grid-KFS-v1.6

Transkrypt

Podobne dokumenty

Usługi katalogowe LDAP w systemie Linux. Integracja autoryzacji

Lista zagadnień II stopień

SAMBA, zaawansowana konfiguracja (PDC, LDAP, replikacja) (kod

certyfikat - DPRS Poland

Instrukcja