Narodowe Archiwum Cyfrowe > Budowa NAC
Plan działania czyli jak to sobie wyobrażamy
Kazimierz Schmidt:
Sam się skrytykuję bo format może być bardzo ważny. Tu też można się wpuścić w maliny. Spróbujcie np przekonwertować plik *.oma na mp3... Ja już to robiłem. Oczywiście miałem legalne oprogramowanie zakupione wraz z urządzeniem (przy okazji "zepsułem" sobie konfiguracje komputera) ale ono nie konwertowało do niczego innego. Trzeba było łapać "w locie" z karty dźwiękowej.
Podsumowując: po prostu wszystko jest ważne i trzeba bardzo uważać aby nie zrobić jakiegoś błędu, który może potem dużo kosztować.
fjgrabowski:
--- Cytat: Kazimierz Schmidt w Wrzesień 17, 2007, ---Czy te trzy wykrzykniki mają oznaczać mnie więcej "pomyliłeś się!!!"?
--- Koniec cytatu ---
Oczywiscie! ;) Glowna wojna byla taka i dlatego zwrocilem na to uwage - ale zgadzam sie tez z tym, co Szanowny Pan napisal, wiec nie widze potrzeby ryzykowania przeprowadzki do SR!
--- Cytat: Kazimierz Schmidt w Wrzesień 17, 2007, ---Dlatego bardzo proszę nie napadajmy na siebie w ten sposób.
--- Koniec cytatu ---
Nie bylo moja intencja napadanie Pana! Chodzi mi wylacznie o to, ze PDF (moim zdaniem...) nie jest najlepszym formatem do prezentacji skanow - co innego gdy sa to dokumenty tekstowe / mieszane.
--- Cytat: Kazimierz Schmidt w Wrzesień 17, 2007, ---Co do księgi półmetrowej grubości to chętnie otworzyłbym nowy temat na tym forum:
"jakie technologie do czego zastosować".
--- Koniec cytatu ---
Tak! Tak! Tak!
Moze jeszcze niesmiertelny problem - co skanowac w pierwszej kolejnosci... Jezeli to nie jest decyzja wylacznie "gory".
--- Cytat: Kazimierz Schmidt w Wrzesień 17, 2007, ---Już tu raz pisałem że nie życzę sobie wydać kilkudziesięciu milionów złotych (moich bo publicznych!) więcej na sprzęt tylko dlatego że są badacze duktu pisma (w liczbie powiedzmy dziesięciu), którzy potrzebują jakości 600 dpi w kolorze i bez kompresji.
--- Koniec cytatu ---
Dodalbym do tego jeszcze jeden aspekt - czas potrzebny na skanowanie w wyzszej rozdzielczosci! Przy olbrzymich ilosciach materialow, staje sie to powaznym problemem...
--- Cytat: Kazimierz Schmidt w Wrzesień 17, 2007, ---Sam się skrytykuję bo format może być bardzo ważny. Tu też można się wpuścić w maliny. Spróbujcie np przekonwertować plik *.oma na mp3... Ja już to robiłem. Oczywiście miałem legalne oprogramowanie zakupione wraz z urządzeniem (przy okazji "zepsułem" sobie konfiguracje komputera) ale ono nie konwertowało do niczego innego. Trzeba było łapać "w locie" z karty dźwiękowej.
Podsumowując: po prostu wszystko jest ważne i trzeba bardzo uważać aby nie zrobić jakiegoś błędu, który może potem dużo kosztować.
--- Koniec cytatu ---
I dlatego wlasnie tak wazna jest otwartosc przyjetych formatow - oczywiscie to niczego nie gwarantuje, ale zwieksza szanse na to, ze niespodzianka sie nie trafi. Znam przyklady bibliotecznych baz danych robionych na poczatku lat 90... Zostala skopiowana baza, a programu nie ma (po szybkiej analizie autor doszedl do wniosku, ze taniej bedzie przepisac od nowa, niz odtwarzac zamkniete oprogramowanie).
Pozdrawiam
JG
ps. Czy sposob udostepnienia danych podpada pod ten watek? Dla przykladu prosze porownac sobie funkcjonalnosc WBC i Polon`y. Niby to samo, a jednak nie... A moze to tylko moje odczucie?
ps2. Panie Rafale, dziekuje za rozwianie moich obaw!!!
Tuptus:
Jako, że pierwszy raz na forum ... witam szanowne towarzystwo.
Nie jestem archiwistą więc nawet nie będę próbował dyskutować o formatach, metadanych itp. Natomiast chciałbym zwrócić uwagę na dwa tematy, których nie zauważyłem w dyskusji.
Pierwsza sprawa to zasilanie zbioru danymi. Jest tu mowa o aplikacji standby oraz interfejsie www. I bardzo dobrze ale czy to wystarczy? Komunikacja między większymi ośrodkami załatwi sprawę ale wspomniano tu również o małych ośrodkach a tutaj już może być problem z komunikacją. W naszym kraju nadal są rejony, w których dostęp do internetu pozostaje w sferze marzeń. Nawet tak popularna Neostrada nie załatwia problemu. Proszę pamiętać, że reklamowana prędkość 1Mbps to prędkość do klienta (download). Transfer w drugą stronę (upload) to zaledwie 128kbps a w lepszych konfiguracjach 256kbps. To stanowczo za mało do przesyłania danych "ważących" po kilka/kilkanaście MB nie mówiąc już o przesłaniu efektów pracy całego dnia. Nie chodzi tu o czas pracy komputera - można upload wykonać w nocy (choć tutaj BHPowcy dostaną białej gorączki) ale o sam mechanizm przekazywania danych. Z różnych względów skrypt działający na serwerze, odbierający dane musi się wykonać w określonym przedziale czasu. Jeśli się nie wykona to jest brutalnie zabijany i komunikacja jest zrywana a dane już przesłane znikają z serwera. Przy tak dużych ilościach danych i szybkościach transferu dostępnych obecnie na rynku za rozsądną cenę nie ma szans na realizacje takiego planu. Pewnym rozwiązaniem mogłoby być zastosowanie rozwiązania z dawnych lat nazywanego żartobliwie "floppy network". Wymagałoby to dodania do aplikacji "standby" funkcji eksportu na nośnik wymienny a do aplikacji działającej na serwerze funkcji importu danych z takiego nośnika.
Kolejna sprawa to samo przechowywanie danych. Szukając informacji o polskich archiwach trafiłem na przetarg ogłoszony przez AAN i na tym przykładzie wyjaśnię o co chodzi. W SIWZ podano, że dostarczonych ma być 12 dysków po 500GB (to tak na początek). Przyjmując że będą pracować w RAID 1 to daje 3TB danych. W jaki sposób wykonać backup takiej ilości danych? SIWZ wymienia jeden napęd LTO4. Teoretyczna prędkość wykonania kopii na tym streamerze to 430GB/h, w praktyce ok. 300GB/h. Zatem wykonanie pełnej kopii zajmie ok. 10h. Czy w tak długim czasie nie nastąpią żadne zmiany w zbiorze danych? Jeśli nastąpią to kopia będzie nic nie warta bo dane będą niespójne. Oczywiście można zamiast pełnego backupu wykonywać kopie przyrostowe. Ale w jaki sposób określimy na której taśmie znajdują się określone dane?
Analizując dalej problem przechowywania danych ... Jak miałby być określony sposób dostępu do danych? Początkowo wszystkie dane będą się znajdować na dyskach serwera ale z czasem danych będzie tyle, że zabraknie miejsca. Oczywiście można dokupić kolejne dyski ale w pewnym momencie skończą się możliwości rozbudowy sprzętu a dokładanie kolejnych elementów spowoduje zbyt duży stopień skomplikowania konfiguracji systemu. Tutaj pewnym rozwiązaniem mogłoby być zastosowanie klas dostępu: dokumenty bieżące, dokumenty często przeglądane, dokumenty rzadko przeglądane ... W oparciu o tak zdefiniowane klasy i ich wymogi czasu dostępu można dobrać różnego rodzaju nośniki i sposób przechowywania danych oraz oprogramowanie do zarządzania takim zasobem.
Skoro wspomniałem o oprogramowaniu ... Do backupu tak dużych danych zwróciłbym uwagę na aplikacje Legato oraz TSM (niestety obie własnościowe i kosztują :o ) oraz system Bacula (to już OS).
Niestety wszystkie te aplikacje mają na celu zabezpieczenie danych przed utratą a nie ich archiwizację. Wszystkie one zakładają możliwość "znikania" danych po określonym czasie (retencja danych). Zresztą nie jest to takie dziwne. Z doświadczenia wiem, że taśmy, nawet przechowywane w warunkach wręcz laboratoryjnych, po trzech latach zaczynają sprawiać problemy przy próbie odtworzenia danych. Więc pojawia się kolejny problem do rozwiązania: okresowe odtwarzanie danych i ponowny zapis na taśmach.
MSZ temat przechowywania i udostępniania danych jest na tyle istotny, że należałoby go ująć jako kolejny projekt.
fjgrabowski:
Pozwole sobie odpowiedziec:
Ad1
Nie jest mozliwym, aby w kazdym archiwum znalazl sie odpowiedniej jakosci skaner i osoba(y), ktora by przy nim pracowala. Przypuszczam, ze bedzie pare (pewnie nawet nie tyle, ile wojewodztw) osrodkow skanowania i tam beda trafialy akta z mniejszych placowek.
Ad2
Przechowywanie to spory problem. Wystarczy to sobie policzyc! Przykladowy skan, ktory dostaje sie od AGAD ma 20MB (a pewnie beda lepszej jakosci), ksiega ma np. kart 400 (czyli 800 skanow). Daje to 15,5GB. Ksiag w serii jest np. 200. Co daje nam dla jedenego zespolu (?) 3TB danych. Na jedna tasme nie ma szansy tego upchnac (chyba najwieksze w tej chwili maja 400GB - po kompresji 800). Zmian w tym materiale juz nie ma, wobec czego mozna nagrywac tak dlugo jak sie chce.
Zywotnosc? Firma SUN daje 30 lat (zrodlo).
Nie bardzo chce mi sie wglebiac w ich strone, zeby sprawdzic na ile daja gwarancje.
Oczywiscie jedna kopia, to jest zbyt malo. Trzeba miec odpowiednie pomieszczenia do przechowywania itd. Ale to i tak wyjdzie taniej, niz trzymanie tego calego materialu na macierzach (bo jaki jest sens, jezeli to maja byc kopie bezpieczenstwa?).
Nie wglebiam sie bardziej, bo juz pozno - a pisac mozna duzo na ten temat.
Pozdrawiam
JG
Tuptus:
--- Cytat: fjgrabowski w Wrzesień 22, 2007, ---Ad1
Nie jest mozliwym, aby w kazdym archiwum znalazl sie odpowiedniej jakosci skaner i osoba(y), ktora by przy nim pracowala. Przypuszczam, ze bedzie pare (pewnie nawet nie tyle, ile wojewodztw) osrodkow skanowania i tam beda trafialy akta z mniejszych placowek.
--- Koniec cytatu ---
W takim razie po co aplikacja na PC. Przecież te kilka jednostek może pracować online dostarczając dane bezpośrednio na serwery.
Czy nie prościej jest wykonać skan materiałów w archiwum, w którym materiały są przechowywane i taką "surówkę" już w postaci elektronicznej dostarczyć do ośrodka przetwarzania?
--- Cytuj ---Ad2
Przechowywanie to spory problem. Wystarczy to sobie policzyc! Przykladowy skan, ktory dostaje sie od AGAD ma 20MB (a pewnie beda lepszej jakosci), ksiega ma np. kart 400 (czyli 800 skanow). Daje to 15,5GB. Ksiag w serii jest np. 200. Co daje nam dla jedenego zespolu (?) 3TB danych. Na jedna tasme nie ma szansy tego upchnac (chyba najwieksze w tej chwili maja 400GB - po kompresji 800). Zmian w tym materiale juz nie ma, wobec czego mozna nagrywac tak dlugo jak sie chce.
Zywotnosc? Firma SUN daje 30 lat (zrodlo).
Nie bardzo chce mi sie wglebiac w ich strone, zeby sprawdzic na ile daja gwarancje.
--- Koniec cytatu ---
W zeszłym roku do sprzedaży weszły napędy i media LTO4 o pojemności 800/1600 GB i o takich właśnie pisałem. Rozwiązania takie jak podane w linku traktowałbym bardzo ostrożnie gdyż nie jest to standard i wybierając takie rozwiązanie skazujemy się na dożywotnie związanie z jednym producentem.
A co do żywotności:
--- Cytat: http://h18006.www1.hp.com/storage/tapestorage/storagemedia/tape_ultrium/index.html ---HP warrants LTO4 Ultrium 1.6TB RW and WORM cartridges for up to 30 years archival life and/or 260 full backups. This ensures businesses can meet the ever increasing demands of regulation for data retention and archiving.
--- Koniec cytatu ---
Faktycznie czas życia jest dłuższy od tego co wcześniej pisałem ale czy możemy przyjąć 30 lat? Taki okres przydatności do użycia ma medium ale czy dane tyle przetrwają. Mam co do tego poważne wątpliwości. Jakikolwiek jest to okres i tak nie zmienia to faktu, że dane na taśmach należy okresowo "odświeżać" i dobrze by było mieć jakiś automat, który będzie o tym pamiętał.
--- Cytuj ---Oczywiscie jedna kopia, to jest zbyt malo. Trzeba miec odpowiednie pomieszczenia do przechowywania itd. Ale to i tak wyjdzie taniej, niz trzymanie tego calego materialu na macierzach (bo jaki jest sens, jezeli to maja byc kopie bezpieczenstwa?).
--- Koniec cytatu ---
Kopie bezpieczeństwa jak najbardziej na tasiemki i przechowywanie w innej lokalizacji niż oryginały.
Ale przecież celem projektu jest ułatwienie dostępu do danych a więc możliwość szybkiego i prostego dostępu do nich. Właśnie dlatego wspomniałem o klasach dostępności. Przykładowo:
1. dane w formie "bezpośredniej" zgromadzone na głównej macierzy dyskowej
2. dane w formie skompresowanej na dodatkowej macierzy dyskowej - są już dostępne dyski o pojemności 1TB, dostęp bezpośrednio do poszukiwanego zasobu po jego rozkompresowaniu
3. dane w formie skompresowanej przechowywane w bibliotece taśmowej dostępne na żądanie oprogramowania - dostęp do danych jest sekwencyjny (długi czas dostępu do danych), wymaga przeniesienia na wyższy poziom dostępności w celu rozkompresowania
4. dane na taśmach dostępne po wcześniejszym zamówieniu dostępu - znajdują się w magazynie danego ośrodka
Ten przykład pokazuje sposób przechowywania i udostępniania danych a nie ich zabezpieczenia bo to odrębna problematyka.
Oczywiście powyższe dotyczy przechowywania danych właściwych bo metadane muszą być dostępne online i umożliwiać identyfikację klasy dostępności i tutaj właśnie dochodzimy do problemu spójności danych. Jeśli w czasie wykonywania backupu klient zgłosi zapotrzebowanie na dany zasób to zostanie on przeniesiony na wyższy poziom dostępności i zostaną dokonane odpowiednie zmiany w informacji o tym zasobie. Ale czy wszystkie te zmiany zostaną przeniesione do backupu? Tutaj nie mamy pewności. Oczywiście jest to problem stary jak informatyka i istnieje wiele mechanizmów zabezpieczających ale trzeba je zaimplementować do konkretnej instalacji.
Nie chodzi mi w tej chwili o rozwiązanie przedstawionych problemów ale o to aby o tych problemach nie zapominano i uwzględniono je przy projektowaniu całego systemu. Jest to temat bardziej dla informatyków i dlatego sugeruję wydzielenie go jako odrębny podprojekt w ramach NAC.
Nawigacja
[#] Następna strona
Idź do wersji pełnej