Tworzenie zewnętrznego rozwiązania magazynowego dla SharePoint

Autor: Pav Cherny

Opublikowano: 28 października 2009

Zawartość strony

	Wewnętrzny magazyn binariów
	Zewnętrzny magazyn binariów
	Budowanie niezarządzanego dostawcy EBS
	Budowanie zarządzanego dostawcy EBS
	Rejestrowanie dostawcy EBS w SharePoint
	Implementacja odśmiecania
	Podsumowanie

Firma Microsoft oszacowuje, że niemal 80 procent wszystkich danych przechowywanych w bazie danych zawartości Microsoft Windows SharePoint Services ( WSS ) 3.0 oraz Microsoft Office SharePoint Server (MOSS) 2007 stanowią dane nierelacyjnych wielkich obiektów binarnych (BLOB), takie jak dokumenty Microsoft Office Word, arkusze Microsoft Office Excel lub prezentacje Microsoft Office PowerPoint. Jedynie 20 procent stanowią relacyjne metadane, z czego wynika nieoptymalne wykorzystanie zasobów Microsoft SQL Server stanowiącego podstawę bazodanową. SharePoint nie potrafi wykorzystać najnowszych innowacji wprowadzonych w SQL Server dla danych niestrukturalnych, dostępnych w SQL Server 2008, takich jak atrybut FILESTREAM czy Remote BLOB Storage API, ale oferuje własne opcje pozwalające na poprawę wydajności magazynu i zarządzania masywnymi woluminami danych.

Konkretyzując: SharePoint zawiera API zewnętrznego dostawcy magazynu binarnego, ISPExternalBinaryProvider, który firma Microsoft opublikowała jako poprawkę w maju 2007 roku i następnie włączyła do Service Pack 1. API ISPExternalBinaryProvider API jest niezależne od API Remote BLOB Storage. Niezależni dostawcy oprogramowania mogą wykorzystać to API do integracji SharePoint z zawansowanymi rozwiązaniami magazynowymi, takimi jak magazyny adresowalne treściowo (content-addressable storage ‑ CAS). API to można również wykorzystać do utrzymywania danych BLOB SharePoint na centralnym serwerze plików na zewnątrz baz danych zawartości, jeśli chcemy zbudować niestandardowe rozwiązanie zwiększające wydajność magazynowania i skalowalność farmy SharePoint. Należy jednak pamiętać, że API to jest specyficzne dla WSS 3.0 oraz MOSS 2007. Zostanie ono zmienione w kolejnym wydaniu oprogramowania SharePoint, co oznacza, że konieczne będzie uaktualnienie dostawcy.

W tym artykule przedstawię sposoby rozszerzenia architektury magazynowej SharePoint przy użyciu API ISPExternalBinaryProvider, łącznie z korzyściami i wadami, szczegółami implementacji, uwarunkowaniami wydajnościowymi i mechanizmami porządkowymi. Przedstawię także problem dotyczący kompatybilności 64-bitowej wersji Microsoft Visual Studio, który może spowodować, że SharePoint nie zdoła załadować zarządzanych komponentów ISPExternalBinaryProvider pomimo poprawnej implementacji interfejsu. Tam, gdzie jest to potrzebne, odwołuję się do dokumentacji ISPExternalBinaryProvider zawartej w WSS 3.0 SDK. Innym źródłem wartym wspomnienia jest blog Kyle’a Tillmana.

Kyle Tillman wykonał świetną robotę, wyjaśniając, jak pokonał przeszkody implementacji w zarządzanym kodzie, ale ani WSS 3.0 SDK, ani blog Kyle’a nie zawiera przykładowego projektu Visual Studio, zatem zdecydowałem się na przygotowanie takich przykładów ISPExternalBinaryProvider zarówno dla kodu niezarządzanego, jak i zarządzanego w materiałach towarzyszących temu artykułowi. Celem tych przykładów jest ułatwienie rozpoczęcia tym Czytelnikom, którzy są zainteresowani integracją zewnętrznych rozwiązań magazynowych z witrynami SharePoint. Należy jednak pamiętać, że przykłady te nie zostały przetestowane i nie są gotowe do użycia w środowiskach produkcyjnych.

Wewnętrzny magazyn binariów

Domyślnie SharePoint przechowuje dane BLOB w kolumnie Content tabeli AllDocStreams bazy danych zawartości. Oczywistą korzyścią tego rozwiązania jest spójność transakcyjna pomiędzy danymi relacyjnymi i powiązanymi z nimi nierelacyjnymi danymi plikowymi. Na przykład wstawianie metadanych dokumentu Word wraz z niestrukturalną zawartością do danych bazy zawartości nie jest skomplikowane, tak samo jak nie jest skomplikowane powiązanie metadanych z odpowiednią niestrukturalną zawartością w operacjach SELECT, UPDATE czy DELETE. Jednak domyślne rozwiązanie ma jedną oczywistą wadę: jest to nieefektywne wykorzystanie zasobów magazynowych. Bez względu na optymalizację podsystemu wejścia/wyjścia mechanizm składowania danych SQL Server nie jest zamiennikiem serwera plików.

Baza danych SQL Server składa się z dzienników transakcji i plików danych, co ilustruje Rysunek 1. W celu zagwarantowania niezawodnego działania transakcyjnego SQL Server najpierw zapisuje wszystkie rekordy transakcji do pliku dziennika, zanim prześle odpowiadające im dane podzielone na strony o wielkości 8KB do pliku danych na dysku. Zależnie od wybranego modelu przywracania wymaga to pojemności magazynu ponad dwukrotnie przekraczającego wielkość obiektu BLOB do chwili wykonania kopii zapasowej i wyczyszczenia dziennika transakcji. Co więcej, SQL Server nie przechowuje niestrukturalnej zawartości SharePoint bezpośrednio w stronach danych. Zamiast tego SQL Server wykorzystuje oddzielny zbiór stron tekstowo/obrazowych, zaś w wierszu danych umieszcza tylko 16-bajtowy wskaźnik tekstowy do węzła źródłowego (root node) obiektu BLOB. Strony tekstowo/obrazowe są uporządkowane jako drzewo zrównoważone, zatem istnieje tylko jeden zbiór tych stron dla każdej tabeli. Dla tabeli AllDocStreams oznacza to, że zawartość wszystkich plików jest rozproszona po tym samym zbiorze stron. Pojedyncza strona tekstowo/obrazowa może przechowywać fragmenty wielu obiektów BLOB albo pośrednie węzły obiektów BLOB przekraczających wielkość 32KB.

Rysunek 1: Domyślny mechanizm przechowywania obiektów BLOB SharePoint w SQL Server.

Nie będziemy jednak nadmiernie zagłębiać się w tajniki SQL Server. Istotny, jest fakt, że podczas odczytywania niestrukturalnej zawartości SQL Server musi przejść przez wiersz danych, aby uzyskać wskaźnik tekstowy, po czym przez główny węzeł obiektu BLOB i (być może) dodatkowe węzły pośrednie, aby zlokalizować wszystkie fragmenty danych, rozproszone po dowolnej liczbie stron, które musi następnie w całości załadować do pamięci, aby uzyskać wszystkie bloki danych. Wynika to z tego, że SQL Server wykonuje operacje wejścia/wyjścia na poziomie stron. Ta złożoność obniża wydajność przesyłania plików w porównaniu z bezpośrednim dostępem poprzez system plików. SQL Server dodatkowo narzuca sztywne ograniczenie 2GB ze względu na to, że jest to maksymalna wielkość danych o typie image. Kolumna Content tabeli AllDocStreams ma typ image, zatem nie można w bazie danych zawartości SharePoint przechowywać plików większych niż 2GB.

 Do początku strony

Zewnętrzny magazyn binariów

API ISPExternalBinaryProvider API udostępnia zręczniejszą alternatywę dla wewnętrznego przechowywania obiektów BLOB w bazach danych zawartości SharePoint. Jest to bezpośredni interfejs COM dysponujący tylko dwiema metodami (StoreBinary oraz RetrieveBinary), który daje się wykorzystać do implementacji dostawcy zewnętrznego magazynu binariów (External Binary Storage – EBS). Szczegóły architektury można znaleźć w temacie „Architecture of External BLOB Storage” w WSS 3.0 SDK.

SharePoint ładuje dostawcę EBS po ustawieniu właściwości ExternalBinaryStoreClassId lokalnego obiektu SPFarm object (SPFarm.Local.ExternalBinaryStoreClassId) na identyfikator klasy COM (CLSID) dostawcy. Następnie SharePoint wywołuje metodę StoreBinary dostawcy, gdy dostarczane są dane BLOB, na przykład – gdy użytkownik ładuje plik do biblioteki dokumentów. Dostawca EBS może zdecydować o przechowaniu obiektu BLOB w powiązanym zewnętrznym systemie magazynowym, zwracając odpowiadający obiektowi identyfikator BLOB ( BLOB ID) do SharePoint, albo też może ustawić parametr pfAccepted metody StoreBinary na wartość False, aby zaznaczyć, że obiekt BLOB nie został obsłużony. W tym wypadku SharePoint przechowuje obiekt BLOB w bazie danych zawartości – jak zwykle. Z drugiej strony jednak, jeśli dostawca EBS zaakceptuje BLOB, SharePoint wstawi tylko BLOB ID do kolumny Content tabeli AllDocStreams, co pokazuje Rysunek 2. BLOB ID może być dowolną wartością pozwalającą dostawcy EBS zlokalizować zawartość w zewnętrznym systemie magazynowym, takim jak nazwa pliku, ścieżka, globalnie unikatowy identyfikator (GUID) czy streszczenie zawartości. Przykładowi dostawcy zawarci w materiale towarzyszącym artykułowi wykorzystują GUID jako nazwy plików w celu niezawodnej identyfikacji obiektów BLOB na serwerze plików.

Rysunek 2: Przechowywanie obiektu BLOB SharePoint w zewnętrznym systemie magazynowym.

SharePoint przechowuje informacje o zewnętrznie składowanych plikach poprzez ustawienia najstarszego bitu flagi DocFlags dla tych plików. DocFlags jest kolumną w tabeli AllDocs. Gdy użytkownik żąda pobrania pliku, SharePoint sprawdza wartość DocFlags i przesyła wartość Content tabeli AllDocStreams do metody RetrieveBinary dostawcy EBS. W odpowiedzi na to wywołanie dostawca EBS musi odczytać wskazany BLOB z zewnętrznego systemu magazynowego i przekazać zawartość binarną do SharePoint w postaci obiektu COM z zaimplementowanym interfejsem ILockBytes. Zwróćmy uwagę, że SharePoint nie wywołuje metody RetrieveBinary dla obiektów BLOB, które są przechowywane bezpośrednio w bazie danych zawartości.

Warto również zauważyć, że procesy zapisywania i odczytywania są przezroczyste dla użytkownika, o ile nie próbuje on pominąć mechanizmów SharePoint. Tak więc nie ma potrzeby zastępowania wbudowanych elementów Web part niestandardowymi wersjami, które wiązałyby metadane list z dokumentami przechowywanymi zewnętrznie; aplikacje produkcyjne, takie jak Microsoft Office, nie muszą wiedzieć, jak przechowywać metadane w jednym miejscu, a dokument w innym, zaś mechanizm wyszukiwania nie musi przetwarzać metadanych w oderwaniu od dokumentów. Co więcej – i to jest jedną z moich ulubionych korzyści wynikających z architektury dostawcy EBS – użytkownik musi przejść przez SharePoint, aby uzyskać dostęp do zewnętrznie przechowywanych danych BLOB. Użytkownik omijający SharePoint i bezpośrednio odwołujący się do bazy danych zawartości poprzez połączenie z SQL Server otrzymuje tylko BLOB ID zamiast faktycznej zawartości pliku, co ilustruje Rysunek 3. Można zweryfikować to zachowanie, wdrażając SQL Download Web Part (który wykorzystałem w artykule z kwietnia 2009 w celu zademonstrowania sposobu ominięcia zabezpieczeń SharePoint AD RMS) w środowisku testowym. Wreszcie użytkownicy nie potrzebują – i nie powinni mieć – praw dostępu do zewnętrznego magazynu BLOB. Tylko konta zabezpieczeń SharePoint wymagają dostępu, gdyż SharePoint wywołuje metody dostawcy EBS w kontekście zabezpieczeń konta, w którym uruchomiona jest pula aplikacji witryny.

Rysunek 3: Dostawca EBS stanowi szlaban dla prób omijania uprawnień SharePoint przy pobieraniu plików.

Należy jednak pamiętać, że dostawcy EBS mają też pewne wady związane ze złożonością utrzymania integralności pomiędzy metadanymi przechowywanymi w bazach danych zawartości farmy SharePoint a zewnętrznym magazynem BLOB. Ciekawe omówienie zalet i wad takich rozwiązań znaleźć można pod tematem „Operational Limits and Trade-Off Analysis” w WSS 3.0 SDK. Koniecznie należy przeczytać ten rozdział przed wdrożeniem dostawcy EBS w środowisku SharePoint.

 Do początku strony

Budowanie niezarządzanego dostawcy EBS

Spróbujmy teraz zmierzyć się z wyzwaniem budowy dostawców EBS. Interfejs ISPExternalBinaryProvider jest dobrze udokumentowany w WSS 3.0 SDK, w części „The BLOB Access Interface: ISPExternalBinaryProvider”. Wydaje się jednak, że firma Microsoft zapomniała o omówieniu szczegółów dostawcy EBS. Ostatecznie nie zamierzamy jedynie wykorzystać interfejsu istniejącego serwera COM. Naszym zadaniem będzie samodzielne zbudowanie tego serwera COM i zaimplementowanie w nim interfejsu ISPExternalBinaryProvider. Co ważniejsze, w WSS 3.0 SDK nie ma wzmianki o typie serwera COM, który mamy zbudować ani o wymaganym modelu wątkowania. Klasyczny serwer COM może działać w trybie zewnątrzprocesowym (out-of-process) albo wewnątrzprocesowym (in-process) i wspierać model jednowątkowy (single-threaded apartment – STA), wielowątkowy (multithreaded apartment –  MTA) lub obydwa, a nawet model free-threaded. Aby dostawca EBS działał właściwie, należy upewnić się, że zbudujemy serwer COM wewnątrzprocesowy o bezpiecznych wątkach (thread-safe), wspierający obydwa modele wątkowania (STA i MTA).

Trzeba również zastanowić się nad wyborem języka programowania. Jest to ważne, gdyż interfejs ISPExternalBinaryProvider stanowi API najniższego poziomu dostępne w SharePoint. Problemy wydajności mogą mieć wpływ na całą farmę SharePoint. Z tego względu zalecam wykorzystanie języka, który pozwoli zbudować małe i szybkie obiekty COM, takiego jak Visual C++ oraz Active Template Library (ATL). ATL udostępnia przydatne klasy C++, upraszczające projektowanie serwerów COM thread-safe w kodzie niezarządzanym z właściwym poziomem obsługi wątkowania.

Visual Studio zawiera również różne kreatory ATL. Wystarczy utworzyć projekt ATL, wybrać bibliotekę dynamiczną (DLL) jako typ serwera, skopiować definicję interfejsu ISPExternalBinaryProvider z WSS 3.0 SDK do pliku języka definicji interfejsu (IDL) tworzonego projektu ATL, dodać nową klasę ATL Simple Object, wybrać „Both” jako model wątkowania oraz brak agregacji, po czym kliknąć nową klasę prawym klawiszem myszy, wskazać Add, kliknąć Implement Interface i zaznaczyć ISPExternalBinaryProvider. To wszystko! Kreator Implement Interface Wizard wykona całą niezbędną infrastrukturę, zatem można będzie skupić się na implementacji metod StoreBinary i RetrieveBinary.

I nie należy bać się niezarządzanego kodu C++. Jeśli przeanalizujemy plik SampleStore.cpp dołączony do artykułu, możemy zobaczyć, że implementacje metod StoreBinary i RetrieveBinary są stosunkowo proste. Mówiąc w skrócie, przykładowa metoda StoreBinary buduje ścieżkę pliku w oparciu o wartość rejestru StorePath, identyfikator Site ID przekazany z SharePoint oraz GUID wygenerowany dla BLOB, po czym wykorzystuje funkcję Win32 WriteFile do zapisania danych binarnych, uzyskanych z wystąpienia ILockBytes. Z drugiej strony przykładowa metoda RetrieveBinary konstruuje ścieżkę w oparciu o tę samą wartość rejestru StorePath, Site ID oraz BLOB ID przekazany przez SharePoint, po czym używa funkcji Win32 ReadFile do odczytania niestrukturalnych danych, które dostawca EBS kopiuje do nowej instancji ILockBytes, a ona z kolei przekazuje je z powrotem do SharePoint. Rysunek 4 ilustruje budowanie ścieżki pliku przez dostawcę EBS.

Rysunek 4: Konstruowanie ścieżek plików dla operacji StoreBinary i RetrieveBinary w przykładowych dostawcach EBS.

 Do początku strony

Budowanie zarządzanego dostawcy EBS

Oczywiście programiści tworzący rozwiązania SharePoint mogą preferować korzystanie z przyjaznych języków zarządzanych do budowy dostawców EBS, mimo że niekoniecznie będzie to mniej skomplikowane niż tworzenie dostawców niezarządzanych ze względu na złożoność współdziałania COM. Należy pamiętać, że aplikacja napisana w kodzie niezarządzanym może załadować tylko jedną wersję CLR, zatem tworzony kod musi współpracować z tą samą wersją CLR, której używa reszta SharePoint. Inaczej możemy doprowadzić do nieoczekiwanych zachowań. Ponadto nadal trzeba poradzić sobie z niezarządzanymi interfejsami i wynikającą stąd koniecznością przekierowywania parametrów i buforów. Wystarczy porównać SampleStore.cpp i SampleStore.cs zawarte w dołączonym materiale. Nie ma tu żadnych korzyści z wykorzystania kodu zarządzanego, jeśli chodzi o strukturę kodu czy prostotę programowania.

Co więcej, należy pamiętać o problemach kompatybilności przy projektowaniu zarządzanych dostawców EBS na platformie x64. Rysunek 5 ukazuje typowy błąd wynikający z nieprawidłowych ustawień rejestracji COM na komputerze projektowym. Jeśli włączymy opcję Register for COM Interop we właściwościach projektu w Visual Studio 2005 lub Visual Studio 2008, otrzymamy w efekcie ustawienia rejestracji COM tworzonego dostawcy w kluczu rejestru HKEY_CLASSES_ROOT\Wow6432Node\CLSID\<ProviderCLSID>. Visual Studio używa 32-bitowej wersji Assembly Registration Tool (Regasm.exe) nawet na platformie x64.

Rysunek 5: Z powodu nieprawidłowych ustawień rejestracji COM nie można załadować zarządzanego dostawcy EBS.

Jednak 64-bitowa wersja SharePoint nie może załadować 32-bitowego serwera COM zarejestrowanego w kluczu Wow6432Node, zatem musimy ręcznie zarejestrować zarządzanego dostawcę EBS przy użyciu 64-bitowej wersji Regasm.exe, zlokalizowanej w katalogu %WINDIR%\Microsoft.NET\Framework64\v2.0.50727. Na przykład polecenie "%WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe" ManagedProvider.dll utworzy właściwe wpisy rejestru dla przykładowego dostawcy zarządzanego w kluczu HKEY_CLASSES_ROOT\CLSID\<ProviderCLSID>. Innym rozwiązanie jest utworzenie programu instalacyjnego i oznaczenie automatycznej rejestracji COM dla dostawcy EBS.

Trzeba też pamiętać, że zarządzani dostawcy EBS niosą ze sobą znacząco większą nadmiarowość i spadek wydajności niż ich niezarządzani odpowiednicy ATL. Można się o tym przekonać, porównując ustawienia rejestracyjne COM w rejestrze. Jak widać w kluczu InProcServer32, kod czasu wykonania COM ładuje biblioteki DLL niezarządzanego dostawcy EBS bezpośrednio, podczas gdy zarządzani dostawcy EBS opierają się na Mscoree.dll jako na serwerze pośredniczącym, czyli na bazowym silniku CLR. Tak więc w przypadku zarządzanych dostawców COM ładuje CLR, po czym CLR ładuje asemblację dostawcy EBS jako zarejestrowaną w kluczu Assembly, a następnie tworzy proxy COM Callable Wrapper (CCW) do obsługi interakcji pomiędzy niezarządzanym klientem SharePoint (Owssvr.dll) a zarządzanym dostawcą EBS.

Pamiętajmy, że niezarządzany serwer SharePoint nie wykonuje bezpośredniej interakcji z zarządzanym dostawcą. To CCW przekierowuje parametry, wywołuje zarządzane metody i obsługuje zwracane HRESULT. Ta niebezpośredniość jest szczególnie widoczna w różnicy typów zwracanych przez zarządzane metody w porównaniu z metodami niezarządzanymi. Niezarządzane metody zwracają HRESULT w celu oznaczenia sukcesów lub porażek, podczas gdy po metodach zarządzanych spodziewamy się pustego typu zwracanego. Nie możemy zatem zwrócić jawnego HRESULT w kodzie zarządzanym. Musimy wywołać wyjątki systemowe lub zdefiniowane przez użytkownika w odpowiedzi na wystąpienie błędu. Jeśli metoda zarządzana zakończy się wyjątkiem, CCW automatycznie zwraca S_OK do niezarządzanego klienta.

Z drugiej strony jednak, jeśli zarządzana metoda wywoła wyjątek, CCW mapuje kody i komunikaty błędów do HRESULT i informacji o błędzie. CCW udostępnia różne interfejsy obsługi błędów dla takich celów, takie jak ISupportErrorInfo lub IErrorInfo, ale SharePoint nie korzysta z tych interfejsów. Dostawcy EBS muszą implementować własny mechanizm raportowania błędów za pośrednictwem dzienników zdarzeń Windows, dzienników diagnostycznych SharePoint, plików śledzenia lub innymi środkami. SharePoint oczekuje jedynie na wartości HRESULT – S_OK dla sukcesu oraz E_FAIL dla dowolnego błędu. Można wykorzystać metodę Marshal.ThrowExceptionForHR, aby zwrócić E_FAIL do SharePoint, co zademonstrowano w pliku SampleStore.cs.

 Do początku strony

Rejestrowanie dostawcy EBS w SharePoint

Najbardziej mylącą częścią opisu ISPExternalBinaryProvider w WSS 3.0 SDK jest temat „Installing and Configuring Your BLOB Provider”. W momencie pisania tego artykułu rozdział ten był pełen nieścisłych informacji i błędów. Nawet polecenia Windows PowerShell były nieprawidłowe. Jeśli przypiszemy dostawcę EBS do zmiennej $yourProviderConfig, a później użyjemy $providerConfig.ProviderCLSID, nie będzie zaskoczeniem otrzymanie komunikatu o błędzie, informującym, że $providerConfig nie istnieje. Oczywiście, nie uda się nawet dotrzeć do tego punktu, gdyż właściwości Active oraz ProviderCLSID nie są częściami interfejsu ISPExternalBinaryProvider. Te tajemnicze właściwości należą do dualnego interfejsu, który nie jest omówiony w dokumentacji! Z ciekawości zaimplementowałem przykładowe wersje zarówno niezarządzanego, jak i zarządzanego kodu, ale implementacja ISPExternalBinaryProvider w ogóle nie wymaga tych zastrzeżonych właściwości.

Właściwość ProviderCLSID mogłaby być przydatna, ale CLSID jest również dostępny w kluczach rejestru, jeśli szukamy ProgID, takich UnmanagedProvider.SampleStore jak ManagedProvider.SampleStore, a ponadto można znaleźć CLSID w plikach kodu SampleStore.rgs oraz SampleStore.cs. Jak wspomniałem wcześniej, ustawienie właściwości ExternalBinaryStoreClassId dla lokalnego obiektu SPFarm na CLSID rejestruje dostawcę EBS. Ustawienie tej właściwości na pusty GUID ("00000000-0000-0000-0000-000000000000") usuwa rejestrację dostawcy EBS. Nie należy zapomnieć o wywołaniu metody Update obiektu SPFarm w celu zapisania zmiany w bazie danych konfiguracji i ponownym uruchomieniu Internet Information Services ( IIS). Poniższy listing pokazuje, jak można zrealizować te zadania w Windows PowerShell:

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint')

$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local



# Rejestrowanie CLSID dostawcy EBS 

$farm.ExternalBinaryStoreClassId = "C4A543C2-B7DB-419F-8C79-68B8842EC005"

$farm.Update()

IISRESET



# Usuwanie rejestracji dostawcy EBS 

$farm.ExternalBinaryStoreClassId = "00000000-0000-0000-0000-000000000000"

$farm.Update()

IISRESET

 Do początku strony

Implementacja odśmiecania

Inny rozdział WSS 3.0 SDK przedstawiający tajemnicze komponenty i krytyczne urywki kodu zatytułowany jest „Implementing Lazy Garbage Collection”. W momencie pisania tego artykułu rozdział ów zawierał odsyłacze do innej tajemniczej klasy Utility z metodami DirFromSiteId oraz FileFromBlobid, jak również nieprawidłowe przypisanie wyników Directory.GetFiles do macierzy FileInfo, ale nie bądźmy za bardzo wymagający, jeśli chodzi o jakość dokumentacji WSS 3.0. Metody pomocnicze DirFromSiteId oraz FileFromBlobid samymi nazwami ukazują swoje przeznaczenie, zaś niepoprawną macierz FileInfo można łatwo zastąpić macierzą łańcuchów albo też można wymienić metodę Directory.GetFiles na wywołanie metody GetFiles obiektu DirectoryInfo. Przykładowy program Garbage Collector zawarty w dołączonym materiale wykorzystuje podejście DirectoryInfo i działa zgodnie z sugerowaną techniką usuwania nieużytków.

Ważnym odchyleniem przykładowego programu Garbage Collector od wyjaśnień i zaleceń SDK jest obsługa warunków czasowych. Jest to problem krytyczny, gdyż warunki czasowe mogą prowadzić do błędnej identyfikacji i usunięcia poprawnych plików podczas procesu odśmiecania. Spójrzmy na Rysunek 6, który ilustruje zalecane przez WSS 3.0 SDK podejście do identyfikowania osieroconych plików poprzez wyliczanie wszystkich plików BLOB w magazynie EBS i następnie usuwanie wszystkich tych odsyłaczy z listy BLOB, utrzymywanej w bazie danych zawartości, zgodnie ze wskazaniem przez zbiór ExternalBinaryIds witryny. Pozostałe wpisy na liście BLOB są uważane za wskaźniki plików osieroconych, które należy usunąć.

Rysunek 6: Błędna identyfikacja ważnego pliku BLOB jako osieroconego z powodu przesunięć czasowych.

Jednak dostawca EBS musi, co oczywiste, najpierw zakończyć zapisywanie danych BLOB, zanim będzie mógł zwrócić BLOB ID do SharePoint. Zależnie od pasma sieciowego i innych warunków wydajności operacji wejścia/wyjścia mogą ulegać fluktuacjom. Istnieje zatem możliwość, że dostawca EBS utworzył nowy BLOB – który pojawi się następnie na liście BLOB – ale zakończy zapisywanie danych BLOB dopiero po sprawdzeniu na liście ExternalBinaryIds, że dany BLOB ID nie występuje w tym zbiorze. W rezultacie odsyłacz do nowego obiektu BLOB pozostanie na liście osieroconych plików. Jeśli w tym momencie wymażemy osierocone pliki BLOB, skasujemy też poprawną zawartość i utracimy dane! W celu uniknięcia takiej sytuacji przykładowy program Garbage Collector sprawdza daty utworzenia plików i dodaje je do listy BLOB dopiero wówczas, gdy od momentu utworzenia minęła co najmniej godzina.

 Do początku strony

Podsumowanie

Dzięki integracji zewnętrznego rozwiązania magazynowego z witryną SharePoint można zwiększyć efektywność magazynowania, wydajności systemu oraz skalowalność farmy SharePoint. Inną przewagą tego rozwiązania jest wymuszenie korzystania przez użytkowników z SharePoint w celu uzyskania dostępu do niestrukturalnej zawartości. Wyciąganie danych przez bezpośrednie połączenia SQL Server zwraca tylko identyfikatory BLOB zamiast właściwych plików. Jednak dostawcy EBS mają również wady, wynikające ze trudności utrzymania spójności pomiędzy metadanymi przechowywanymi w bazach danych farmy SharePoint a zewnętrznym magazynem obiektów BLOB.

W celu zintegrowania SharePoint z zewnętrznym magazynem trzeba zbudować dostawcę EBS, który jest serwerem COM implementującym interfejs ISPExternalBinaryProvider z metodami StoreBinary oraz RetrieveBinary. Można utworzyć dostawców niezarządzanych lub zarządzanych, ale trzeba mieć na uwadze problemy z wydajnością i kompatybilnością przy wyborze zarządzanego kodu. Trzeba też pamiętać, że interfejs ISPExternalBinaryProvider nie zawiera metody DeleteBinary. Konieczne jest jawne usuwanie osieroconych plików BLOB poprzez opóźniony mechanizm odśmiecania i zachować ostrożność przy dobieraniu granic czasowych, aby uniknąć przypadkowego usuwania poprawnych elementów BLOB.

O autorze

Pav Cherny jest ekspertem IT i autorem specjalizującym się w technologiach firmy Microsoft służących współdziałaniu i komunikacji. Jego publikacje obejmują dokumenty techniczne, podręczniki oraz książki skoncentrowane na operacjach IT i administrowaniu systemami. Jest prezesem Biblioso Corporation, firmy specjalizującej się w zarządzanych usługach dokumentacyjnych i lokalizacyjnych.

Do początku strony