Cel systemu
Wsparcie zdalnego dostępu do plików na komputerach w sieci. System "wirtualnie" wspiera wszystkie podstawowe operacje plikowe (tworzenie, usuwanie, odczyt, zapis i inne) poprzez wymianę transakcji (wiadomości) za pomocą protokołu TCP.
Obszary zastosowania
Funkcjonalność systemu jest efektywna w następujących przypadkach:
- w natywnych aplikacjach dla urządzeń mobilnych i embedded (smartfony, systemy zarządzania pokładowego itp.), które wymagają szybkiego dostępu do plików na zdalnych serwerach w warunkach prawdopodobnych przerw w łączności (przechodząc w tryb offline);
- w obciążonych bazach danych, gdy przetwarzanie zapytań odbywa się na jednych serwerach, a przechowywanie danych – na innych;
- w rozproszonych korporacyjnych sieciach zbierania i przetwarzania informacji, wymagających wysokiej prędkości wymiany danych, rezerwacji i niezawodności;
- w złożonych systemach z architekturą mikrousług, gdzie opóźnienia w wymianie informacji między modułami mają krytyczne znaczenie.
Struktura
System Cage (jest dostępna realizacja — wersja beta na Pythonie 3.7 w systemie Windows) obejmuje dwie główne części:
- Cageserver — program serwera plików (pakiet funkcji), który uruchamia się na komputerach w sieci, których pliki wymagają zdalnego dostępu;
- klasa Cage z biblioteką metod dla oprogramowania klienckiego, ułatwiająca kodowanie interakcji z serwerami.
Użycie systemu po stronie klientów
Metody klasy Cage zastępują zwykłe, "rutynowe" operacje systemu plików: tworzenie, otwieranie, zamykanie, usuwanie plików, a także odczyt/zapis danych w formacie binarnym (z określeniem pozycji i rozmiaru danych). Koncepcyjnie te metody są zbliżone do funkcji plikowych języka C, gdzie otwieranie/zamykanie plików odbywa się "na kanałach" wejścia-wyjścia.
Innymi słowy, programista pracuje nie z metodami obiektów "plikowych" (klasy _io w Pythonie), a z metodami klasy Cage.
Podczas tworzenia instancji obiektu Cage nawiązuje on początkowe połączenie z serwerem (lub kilkoma serwerami), przechodzi autoryzację za pomocą Id klienta i otrzymuje potwierdzenie z numerem przydzielonego portu do realizacji wszystkich operacji plikowych. Po usunięciu obiektu Cage wydaje on serwerowi polecenie zakończenia połączenia i zamknięcia plików. Zakończenie połączenia mogą również inicjować same serwery.
System zwiększa wydajność operacji odczytu/zapisu na podstawie buforowania często używanych fragmentów plików w pamięci podręcznej (buforze) pamięci operacyjnej.
Oprogramowanie klienckie może korzystać z dowolnej liczby obiektów Cage z różnymi ustawieniami (pojemność bufora, rozmiar bloków podczas wymiany z serwerem itd.).
Jeden obiekt Cage może wymieniać dane z wieloma plikami na różnych serwerach. Parametry połączenia (adres IP lub DNS serwera, główny port do autoryzacji, ścieżka i nazwa pliku) są określane przy tworzeniu obiektu.
Ponieważ każdy obiekt Cage może jednocześnie pracować z wieloma plikami, do buforowania wykorzystywana jest wspólna przestrzeń pamięci. Rozmiar pamięci podręcznej - liczba stron i ich rozmiar - jest ustalany dynamicznie przy tworzeniu obiektu Cage. Na przykład, pamięć podręczna o pojemności 1 GB to 1000 stron po 1 MB, lub 10 000 stron po 100 KB, lub 1 milion stron po 1 KB. Wybór rozmiaru i liczby stron to konkretne zadanie dla każdego przypadku użycia.
Można jednocześnie używać wielu obiektów Cage, aby ustalić różne ustawienia bufora w zależności od specyfiki dostępu do informacji w różnych plikach. Jako podstawowy zastosowany jest najprostszy algorytm buforowania: po wyczerpaniu ustalonego zakresu pamięci nowe strony wypierają stare na zasadzie minimalnej liczby odwołań. Buforowanie jest szczególnie efektywne w przypadku nierównomiernego (w sensie statystycznym) współdzielenia dostępu, po pierwsze, do różnych plików, a po drugie, do fragmentów każdego pliku.
Klasa Cage wspiera wejście/wyjście nie tylko po adresach danych (z określeniem pozycji i długości tablicy, „zastępując” operacje systemu plików), ale także na niższym, „fizycznym” poziomie - po numerach stron w pamięci podręcznej.
Obiekty Cage obsługują oryginalną funkcję „hibernacji” («sny») – można je „zwinąć” (na przykład w przypadku utraty połączenia z serwerami lub zatrzymania aplikacji itp.) w lokalny plik dump na stronie klienta i szybko przywrócić z tego pliku (po wznowieniu połączenia, przy ponownym uruchomieniu aplikacji). To pozwala na znaczne zmniejszenie ruchu przy aktywacji pracy programu klienckiego po tymczasowym odejściu „w trybie offline”, ponieważ często używane fragmenty plików już będą znajdować się w pamięci podręcznej.
Cage — to około 3600 linii kodu.
Zasady budowy serwerów
Pliki serwerów Cageserver można uruchamiać z dowolną liczbą portów, z których jeden („główny”) jest używany tylko do autoryzacji wszystkich klientów, a pozostałe — do wymiany danych. Program serwera Cage wymaga jedynie Pythona. Równolegle komputer z serwerem plikowym może wykonywać jakąkolwiek inną pracę.
Serwer uruchamia się najpierw jako zbiór dwóch głównych procesów:
- „Połączenia” – proces do realizacji operacji nawiązywania i kończenia połączeń z klientami z inicjatywy serwera;
- „Operacje” – proces do realizacji zadań (operacji) klientów związanych z plikami, a także do zamykania sesji połączeń na polecenia klientów.
Oba procesy nie są synchronizowane i zorganizowane jako nieskończone cykle odbierania i wysyłania wiadomości na podstawie wieloprocesowych kolejek, obiektów proxy, blokad i gniazd.
Proces „Połączenia” przydziela każdemu klientowi port do przesyłania danych. Liczba portów jest określana podczas uruchamiania serwera. Zgodność między portami a klientami jest przechowywana w pamięci proxy dzielonej między procesami.
Proces „Operacje” wspiera podział zasobów plikowych, przy czym kilku różnych klientów może wspólnie (quasi-równolegle, ponieważ dostęp jest zarządzany przez blokady) odczytywać dane z jednego pliku, jeśli zostało to dozwolone podczas jego początkowego otwarcia przez „pierwszego” klienta.
Przetwarzanie poleceń dotyczących tworzenia/usuwania/otwierania/zamykania plików na serwerze jest realizowane w samym procesie „Operacje” ściśle sekwencyjnie z użyciem systemu plików OS serwera.
Aby przyspieszyć operacje odczytu/zapisu, są one wykonywane w wątkach (threads) generowanych przez proces „Operacje”. Liczba wątków zazwyczaj odpowiada liczbie otwartych plików. Zadania na odczyt/zapis od klientów trafiają do wspólnej kolejki, a pierwszy dostępny wątek pobiera zadanie z jej początku. Specjalna logika umożliwia wykluczenie operacji nadpisywania danych w pamięci operacyjnej serwera.
Proces „Operacje” monitoruje aktywność klientów i przerywa ich obsługę zarówno na ich polecenie, jak i po przekroczeniu limitu czasu bezczynności.
Aby zapewnić niezawodność, Cageserver prowadzi dzienniki wszystkich transakcji. Jeden wspólny dziennik zawiera kopie wiadomości od klientów z zadaniami na tworzenie/otwieranie/zmienianie nazw/usuwanie plików. Dla każdego pliku roboczego tworzony jest oddzielny dziennik, w którym zapisywane są kopie wiadomości z zadaniami na odczyt i zapis danych w tym pliku roboczym, a także tablice zapisywanych (nowych) danych oraz tablice danych, które zostały zniszczone w wyniku nadpisania (zapisu nowych danych „na starych”).
Te dzienniki umożliwiają zarówno przywracanie nowych zmian w kopiach zapasowych, jak i „cofanie” się od aktualnej zawartości do określonego momentu w przeszłości.
Cageserver to około 3100 linii kodu.
Uruchamianie programu serwera plików Cageserver
Podczas uruchamiania w dialogu należy określić:
— główny port do autoryzacji;
— liczbę portów do wymiany transakcji z autoryzowanymi klientami (od 1 i więcej, pula numerów zaczyna się od następnego po numerze głównego portu).
Użycie klasy Cage
class cage.Cage( cage_name=», pagesize=0, numpages=0, maxstrlen=0, server_ip={}, wait=0, awake=False, cache_file=»» )
Z tej klasy tworzony jest obiekt, który umożliwia interakcję z serwerami plików i zawiera pamięć buforową.
Ustawienia
- cage_name(str) — nazwa obiektu, która jest używana do identyfikacji klientów po stronie serwera
- pagesize(int) — rozmiar jednej strony pamięci buforowej (w bajtach)
- numpages(int) — liczba stron pamięci buforowej
- maxstrlen(int) — maksymalna długość bajtowego ciągu w operacjach zapisu i odczytu
- server_ip(dict) — słownik z adresami używanymi serwerów, gdzie kluczem jest warunkowa nazwa serwera (id serwera wewnątrz aplikacji), a wartością jest ciąg z adresem: „adres IP:port” lub „DNS:port” (mapowanie nazw i rzeczywistych adresów — tymczasowe, można je zmieniać)
- wait(int) — czas oczekiwania na odpowiedź serwera przy uzyskiwaniu portów (w sek.)
- budzić(boolean) — flaga metody tworzenia obiektu (Fałsz — jeżeli tworzony jest nowy obiekt, Prawda — jeżeli obiekt jest tworzony z wcześniej „wstrzymanego” — zastosowaniem operacji „hibernacji”, domyślnie Fałsz)
- cache_file(str) — nazwa pliku do hibernacji
Metody
Klatka.file_create( serwer, ścieżka ) – utworzyć nowy plik
Klatka.file_rename( serwer, ścieżka, nowa_nazwa ) – zmienić nazwę pliku
Klatka.file_remove( serwer, ścieżka) – usunąć plik
Klatka.open( serwer, ścieżka, mod ) – otworzyć plik
Zwraca fchannel numer kanału. Parametr mod — to tryb otwierania pliku: „wm” — monopolowy (odczyt/zapis), „rs” — tylko odczyt, i dzielony tylko do odczytu przez innych klientów, „ws” — odczyt/zapis, i dzielony tylko do odczytu przez innych klientów.
Klatka.zamknąć (fchannel) – zamknąć plik
Klatka.write (fchannel, begin, data ) – zapisać ciąg bajtów do pliku
Klatka.read (fchannel, begin, len_data ) – odczytać ciąg bajtów z pliku
Klatka.put_pages ( fchannel ) – „wypycha” z bufora na serwer wszystkie zmodyfikowane strony wskazanego kanału. Używane w tych punktach algorytmu, kiedy trzeba się upewnić, że wszystkie operacje na kanale są fizycznie zapisane w pliku na serwerze.
Klatka.push_all () – „wypycha” z bufora na serwer wszystkie zmodyfikowane strony wszystkich kanałów dla instancji klasy Cage. Używane, kiedy trzeba się upewnić, że wszystkie operacje na wszystkich kanałach zostały zapisane na serwerze.
Źródło: habr.com
