Opracowanie solidnej technologii zsynchronizowanej transmisji danych w czasie rzeczywistym z obserwatorium magnetycznego do INTERMAGNET GIN

Ponieważ dostęp do Internetu w CPL jest bardzo ograniczony ze względu na jego lokalizację z dala od miasta, zdecydowaliśmy się na niezawodną stałą instalację światłowodową firmy BSNL (Bharath Sanchar Nigam Limited) zarządzaną przez Govt. z Indii. Jednak konfiguracja i konserwacja były zbyt kosztowne, dlatego skorzystaliśmy z urządzeń lokalnego dostawcy usług o maksymalnej przepustowości 20 Mbit/s, aby zainicjować technologię przesyłania danych.

konfiguracja wstępna

Transfer danych online z CPL do obserwatorium HYB został uruchomiony z wieloplatformowym transferem danych ze względu na niedostępność zasobów ISP (Internet Service Provider). Ponieważ usługodawca nie mógł rozwiązać niektórych problemów na poziomie sieci TCP/IP związanych z transferem danych z jednego komputera z systemem Linux na inny zdalny komputer z systemem Linux, musieliśmy przeprowadzić międzyplatformowy proces przesyłania danych, ponieważ ostateczne dane były wymagane w systemie Windows Kody Matlaba są przetwarzane.

Najpierw skonfigurujemy kilka skryptów powłoki, zadań cron i protokołu rsync do przesyłania danych z rejestratora danych Magrec-4B do pośredniej maszyny Linux (Centos) dostarczonej przez CPL. Dane zostały przeniesione z Magrec-4B na maszynę Linux (backup storage) w dyspozytorni CPL z opóźnieniem 5 minut, a następnie na maszynę Windows (klient) w obserwatorium HYB za pomocą opracowanych przez nas kodów, skryptów i , narzędzia innych firm (rys. 2). Ponieważ przepustowość była niska, zdecydowaliśmy się przenieść dane z komputera z systemem Linux na komputer z systemem Windows w HYB-NGRI w odstępie 1 minuty.

Wieloplatformowy system przesyłania danych z komputera z systemem Linux (dostarczany przez CPL) na komputer z systemem Windows (dostarczany przez HYB) i procent udanego transferu danych między systemami.

Zainstalowaliśmy plik wsadowy z opcją „Anuluj” i potwierdziliśmy opcją „Wyłącz”, aby określić stan połączenia po stronie klienta (komputer z systemem Windows), powtarzany przez domyślny limit czasu 120 s. Sesja rozpoczyna weryfikację identyfikatora hosta nazwa użytkownika i uwierzytelnione wstępnie wprowadzone hasło z kluczem RSA (Rivest, Shamir i Adelman) przez SFTP (Secureed File Transfer Protocol). Terminy „porównywanie” i „synchronizacja” na rysunku pokazują szczegóły przesyłania danych z hosta do komputera klienckiego w konwencjonalnych odstępach czasu co 120 sekund.

Z Magrecc-4B wybraliśmy 9 parametrów danych, jak pokazano na rys. 2, aby przesyłać dane w czasie rzeczywistym do komputera klienckiego. Uwzględniono szczegóły dotyczące rozmiaru pliku, każdego parametru danych oraz pośpiechu, z jakim dane są przesyłane z hosta do komputera klienta. Wartości procentowe w kolumnie 5 na rysunku 2 pokazują proces przesyłania danych i aktualizacji na komputerze klienckim. 100% transfer danych jest osiągany tylko wtedy, gdy dane są kopiowane z najnowszymi rekordami 120s, a dodatkowo komputer kliencki ponownie sprawdza dane, synchronizując wcześniejsze rekordy z bieżącego dnia. Przykład procesu trwałego przesyłania danych z najnowszymi rekordami i procesem aktualizacji przedstawiono również w wierszu 9 na rys.1. Po zsynchronizowaniu danych z najnowszymi rekordami (np. wiersz 9 nazwa pliku na rys. 2), 23% transferu plików staje się 100% po zakończeniu tego zadania, powodując kolejną synchronizację z wcześniej zapisanymi danymi. Rozmiar pliku powyższych dziewięciu parametrów zwiększa się co 120 sekund danych aktualizowanych na komputerze głównym. Cały proces jest powtarzany dla każdego cyklu 120 s, aż do końca dnia.

Ponieważ duża ilość danych musi być przesyłana z obu obserwatoriów, a do codziennego przechowywania danych potrzebna jest dedykowana pamięć masowa, w HYB Observatory skonfigurowaliśmy serwer. Ponadto w CPL niedawno zaktualizowano usługi sieci internetowej wraz ze zwiększoną przepustowością do 50 Mbit/s (jest to dotychczas dostępna maksymalna przepustowość), co pozwoliło nam skonfigurować zautomatyzowaną, solidną technikę transmisji danych dla GIN, oraz szczegóły dotyczące jest to omówione poniżej.

Konfiguracja końcowa

Ponieważ naszym głównym celem było osiągnięcie zautomatyzowanego 1-minutowego transferu danych z obserwatoriów HYB i CPL do GIN, musieliśmy włożyć dodatkowe wysiłki w badania i rozwój, aby opracować solidną konfigurację, która obejmowałaby zarówno sprzęt (tj. wysokiej klasy stację roboczą, konfigurację routera zapory), jak i oprogramowanie . Dlatego kod Pythona, skrypty powłoki, zadania cron i protokół rsync są zaprojektowane tak, aby zapewnić transfer danych bez utraty danych. Nawet jeśli usługi internetowe zostaną odłączone, po ich przywróceniu kod Pythona ponownie sprawdzi dane z ostatniego pomyślnie przesłanego pliku.

Transmisja danych z CPL i HYB do centralnego serwera w obserwatorium HYB odbywa się zgodnie z algorytmem kluczy RSH i SSH, który sam w sobie jest algorytmem silnie zabezpieczonym. Opracowaliśmy system do przesyłania danych w zabezpieczonym i zaszyfrowanym wzorze za pomocą kluczy SSH i przechowywania tego samego zbioru danych na lokalnym serwerze w CSIR-NGRI. Wykorzystaliśmy algorytm RSA SSH (Rivest–Shamir–Adleman), kryptosystem klucza publicznego szeroko stosowany do bezpiecznej transmisji danych. Klucz wygenerowany przez ssh-keygen na maszynie źródłowej (MAGREC-DAS) tworzy dwa pliki, a mianowicie „id_rsa i id_rsa.pub” w katalogu .ssh, który jest udostępniany/kopiowany na maszynę docelową (Centos). Tak więc istnieje doskonały uścisk dłoni między maszyną źródłową a docelową w celu przesyłania danych. Ta konfiguracja pozostaje taka sama, chyba że sieć pozostaje taka sama, dlatego przypisaliśmy statyczny adres IP. Wraz z kluczami ssh napisano kod do przesyłania danych za pomocą „narzędzia rsync” i to samo utkwiło w „crontab”, aby powtórzyć to samo w ramach czasowych 10 sekund. Teraz ta sama technika została również zastosowana w HYB Observatory z maszyny Centos na serwer w celu bezpiecznego i udanego przesyłania danych.

Po udanych pracach badawczo-rozwojowych nad transferem danych z obu obserwatoriów na dedykowany, wysokiej klasy serwer Linux z konfiguracją 24 TB RAID 5 w HYB Observatory, stworzyliśmy indywidualne konta użytkowników na serwerze, tj. IMO-CPL, IMO-HYB do przechowywania otrzymanych danych z odpowiednich obserwatoriów. Opracowany kod Pythona będzie codziennie przesyłał z DAS wiele typów danych i przechowywał je na odpowiednich kontach użytkowników (rys. 3). Skrypty opracowane przez każdy komputer z systemem Linux filtrują dane zgodnie z wymaganiami katalogu (tj. GIN). Posortowane dane z poszczególnych katalogów są przesyłane do INTERMAGNET GIN z opóźnieniem 300 s.

Zautomatyzowany 1-minutowy transfer danych z (a) CPL i (b) Obserwatoria HYB w Edinburgh GIN przy użyciu kodu Pythona.

Po udanej transmisji danych z obu obserwatoriów do GIN napotkaliśmy kilka drobnych problemów, a sposób ich rozwiązania został szczegółowo omówiony:

błąd 1 Po pierwsze, kod Pythona został wykonany przy użyciu „protokołu synchronizacji rsync” z minimalnym opóźnieniem 60 s, aby przesłać dane w czasie rzeczywistym z obu obserwatoriów. Jak donoszą eksperci GIN, z tym czasem opóźnienia te same dane były wielokrotnie wysyłane do odbierającej usługi sieciowej (http://app.geomag.bgs.ac.uk/GINFileUpload/UploadForm.html), rys. 4a, powodując, że pamięć/cache w GIN otrzymuje ogromne ilości danych z obu obserwatoriów. Spowodowało to problemy dla całego serwisu internetowego, ponieważ pliki logów zapełniały się bardzo szybko, a pamięć podręczna danych w serwisie była trudna do wykorzystania, ponieważ zajmowała dużo miejsca na dysku (rys. 4b).

(a) Szczegóły pamięci podręcznej danych dla obu obserwatoriów na stronie INTERMAGNET BGS (b) komunikat o błędzie pokazujący „brak miejsca na dysku” z powodu dużej ilości zduplikowanych danych na serwerze BGS.

rozwiązanie Aby rozwiązać powyższy problem, stworzyliśmy demony działające w tle zamiast „protokołu synchronizacji rsync”, dzięki czemu ponowne sprawdzanie danych co 60 sekund zostało zastąpione 300 sekundami. Demony w backendzie uruchamiają kod Pythona co 300 sekund, aby zapewnić płynny transfer danych w czasie rzeczywistym bez duplikacji (jak pokazano na rys. 3).

Wydanie-2 Po pomyślnej transmisji danych z obu obserwatoriów, usługi rejestracji danych INTERMAGENTU nie były wielokrotnie odtwarzane, mimo że nasz sprzęt i oprogramowanie były nienaruszone. Sprawdziliśmy dzienniki z naszej strony i stwierdziliśmy, że dane zostały pomyślnie przesłane do GIN. Choć rekordy się powiodły, nie wiadomo, dlaczego dane nie zostały zarejestrowane w serwisie INTERMAGNET.

rozwiązanie Powyższy problem został rozwiązany po zaproponowaniu przez ekspertów BGS linku (http://app.geomag.bgs.ac.uk/GINFileUpload/UploadForm.html) przesłać jednodniowy plik, aby sprawdzić, czy się udało, czy nie? Zgodnie z sugestią BGS, jeśli wgrywanie danych nie powiodło się i wystąpiły pewne błędy (rys. 4), to jest problem na serwerze INTERMAGNET. Ta weryfikacja pozwoliła nam mieć pewność, że uruchomiony przez nas kod działa poprawnie (rys. 5).

kontrola krzyżowa (a) CPL i (b) Logi danych HYB z serwera obserwatorium HYB do serwera GIN.