Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Witam

Czy ktoś próbował trzymać pliki z SharePointa na serwerze plików zamiast w SQL - baza danych trzyma tylko informację o lokalizacji pliku na serwerze plików. Wiem, że tak można, mam opisane jak to zrobić - ale zbieram informacje jak takie rozwiązanie działa w praktyce, na ile jest stabilne i jakie problemy mogą wystąpić.

Pozdr
SK

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Sławomir Kłódka:
Witam

Czy ktoś próbował trzymać pliki z SharePointa na serwerze plików zamiast w SQL - baza danych trzyma tylko informację o lokalizacji pliku na serwerze plików. Wiem, że tak można, mam opisane jak to zrobić - ale zbieram informacje jak takie rozwiązanie działa w praktyce, na ile jest stabilne i jakie problemy mogą wystąpić.

Pozdr
SK

Witam
Wielkość bazy wprost zależy od ilości/wielkości ładowanych dokumentów. W moim przypadku użytkownicy dość łatwo szybko zapełnili bazę wielo-megowymi plikami CAD, jak jest włączone wersjonowanie to przyrost może być lawinowy.
Zatem jeśli baza przyrasta z powodu plików to jedynym sensownym rozwiązaniem jest zastosowanie tzw EBS lub RBS filestream provider.
Jest on pomyślany do obsługi tzw BLOBów. Jeśli taka aplikacja (EBS/RBS FSP) jest poprawnie napisana to bedzię mieć konfiguracje wielkości pliku, wtedy każdy plik powyżej np 500 kB będzie traktowany jako BLOB i ładowany poza SQLa
W bazie sharepointa trzymana jest tylko referencja. Z punktu widzenia użytkownika jest to przezroczyste, co więcej duże pliki ładują się (zapis/odczyt) wielokrotnie szybciej.
Odrzuciłem wersję pisania własnego EBS/RBS prowajdera i spośród trzech wybrałem produkt DocAve Extender który z powodzeniem zastosowałem.
Wbrew deklaracjom nie jest on jednak full-cost-free. Tylko licencja jest bezpłatna, a faktyczny koszt to ok 600 Euro / rok za tzw. maintenance;
Drugą opcją jest ładowania plików na klasyczny file system oraz synchronizacja (1:1) udziału sieciowy i wybranej biblioteki . To też testowałem i działa, tylko że kosztuje to znacznie drożej.
Temat jest dość obszerny , mam trochę linków i pdf w temacie w razie czego mogę wysłać mailem

więcej
EBS/RBS file stream provider http://www.avepoint.com/sharepoint-storage-extender-do...
File Connector http://www.avepoint.com/sharepoint-management-of-file-...

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Wielkie dzięki za rzeczową odpowiedź.
SK

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Może to rozwiązanie Ciebie zainteresuje

http://gileshhomedrive.codeplex.com/

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

@Tadeusz

Czy byłbyś skłonny na odpowiedzenie mi na parę pytań odnośnie użycia FSB?

1. Jak wygląda sprawa z mechnizmami kopii zapasowych SharePoint? Czy operacje na poziomie farmy, web aplikacji i kolekcji wykonują się poprawnie w obie strony?
2. Czy przeniesienie kolekcji ze środowiska bez FSP jest problemowe?
3. Chcąc migrować bazę danych z contentem sp na inny serwer SQL musisz pewnie przenieść pliki BLOB ręcznie?
4. Czy są jakies komplikacje w związku z indeksowaniem takiej zawartości?
5. Czy wiesz jaka jest różnica w zajętej przestrzeni dyskowej jeśli BLOB jest umieszczony przez FSB, a w klasycznym podejściu?
6. Czy są jakies ograniczenia w sosowaniu FSB z klastrami/mirroringiem SQL?

Wybacz, że tego tyle jest, ale mnie temat bardzo interesuje, a nie mam czasu by go całkowicie przebadac samodzielnie :)

Pozdrawiam
M.

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Witam,
to się może przydać: http://www.storagepoint.com/
Pozdr.
PM

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Maciej Raczyński:
@Tadeusz

Czy byłbyś skłonny na odpowiedzenie mi na parę pytań odnośnie użycia FSB?

1. Jak wygląda sprawa z mechnizmami kopii zapasowych SharePoint? Czy operacje na poziomie farmy, web aplikacji i kolekcji wykonują się poprawnie w obie strony?

Mechanizm tworzenia kopii musisz przemyśleć i opracować sobie sam. Jeśli masz budżet, to lepszym rozwiązaniem będzie rozejrzenie się za produktem komercyjnym, który to potrafi.

2. Czy przeniesienie kolekcji ze środowiska bez FSP jest problemowe?

Zbyt skrótowe pytanie... jak wygląda źródło, jakie ma cechy ? jakie jest /ma być docelowe ?

3. Chcąc migrować bazę danych z contentem sp na inny serwer SQL musisz pewnie przenieść pliki BLOB ręcznie?

Nie jeśli masz narzędzia, tak jeśli nie masz ;-)

4. Czy są jakies komplikacje w związku z indeksowaniem takiej zawartości?

Nie zawuażyłem

5. Czy wiesz jaka jest różnica w zajętej przestrzeni dyskowej jeśli BLOB jest umieszczony przez FSB, a w klasycznym podejściu?

Musiałbym mieć dwa identyczne środowiska, oba ładować takimi samymi porcjami danych by mieć prawdziwe dane. Kto by to robił ?! Chyba tylko producenci tego typu rozwiązań. Pozostaje : zaufać im + poszukać odpowiedzi w FSB analogach które sa stosowane w innych niż sharepoint rozwiązaniach

6. Czy są jakies ograniczenia w sosowaniu FSB z klastrami/mirroringiem SQL?

NIe wiem

Wybacz, że tego tyle jest, ale mnie temat bardzo interesuje, a nie mam czasu by go całkowicie przebadac samodzielnie :)

Generalna uwaga:
W razie poważnego rozważania implementacji obsługi BLOBÓw za pomocą EBS/RBS provider proszę wziąć pod uwagę że tzw polityka backupu zmienia się dramatycznie
Najkrócej mówiąc :
Natywnie SharePoint ma układ to co widzisz (jako user) jest tym co mam w swojej bazie SQL. Jak odtworzysz bazę to dostaniesz wszystko
SharePoint + EBS/RBS tworzy układ : to co widzisz jako user, jest tym co ma w swojej bazie SQL oraz w składnicy(-ach) plików wyrzuconych poza bazę SQL
W drugim przypadki jak odtworzysz samą baze SQL to dostaniesz (dramatycznie) za mało ...
Konluzja: musi istnieć na każdy stan (np. dzień) backup rozumiany jako kompletne synchronicznie zrobione środowisko
Sharepoint (ustawienia konfiguracyjne) + jego baza SQL + pliki BLOBów składowanych poza bazą
Ja tego tego problemu nie mam bo wszystko ( tzn SPS2010 + jego SQL + BLOBY) jest na jednym wirtualnym serwerze. Jedna jego kopia załatwia całość tematu

To tyle
PS - Myśle o tym aby założyć stronę i tam zamieścić to co do tej pory zgromadziłem bo widzę że zainteresowanie jest spore

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Paweł Marcinkowski:
Witam,
to się może przydać: http://www.storagepoint.com/
Pozdr.
PM

Dobre ale troszkę kosztowne...
… The list price of StoragePoint is $14,995 per web front-end

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Z mojego punktu widzenia to niezależnie od tego czy coś tworzy się samemu, czy kupuje gotowe rozwiązania, to działanie w sferach disaster recovery, availability i scalability jest najważniejsze.

Rozwiązanie jednoserwerowe jest proste i przyjemne, ale takie samo podejście nie znajduje zastosowania w 3 poziomowej farmie.

Stąd na razie wychodzą mi tezy, że EBS/RBS:
1. Komplikuje strategię disaster recovery, bo rezygnujemy ze standardu,
2. Niesie ze sobą ekstra koszty (albo kupno, albo development),
3. Jako rozwiązanie po części SQL-owe nie jest wiadome jak zachowuje się w zw. z mirroringiem.
*4. Nie można określić korzyści wyrażonej w zasobach i wydajności*,
5. Migracja wymaga narzędzi.

Pozostaje obalić, lub potwierdzić te punkty :)

Jak na razie brakuje mi jasnego uzasadnienia w jakim celu stosować to rozwiązanie.

P.S.
15.000 $ per Web Serwer to fura pieniędzy

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Maciej Raczyński:
Z mojego punktu widzenia to niezależnie od tego czy coś tworzy się samemu, czy kupuje gotowe rozwiązania, to działanie w sferach disaster recovery, availability i scalability jest najważniejsze.

Rozwiązanie jednoserwerowe jest proste i przyjemne, ale takie samo podejście nie znajduje zastosowania w 3 poziomowej farmie.

Stąd na razie wychodzą mi tezy, że EBS/RBS:
1. Komplikuje strategię disaster recovery, bo rezygnujemy ze standardu,
2. Niesie ze sobą ekstra koszty (albo kupno, albo development),
3. Jako rozwiązanie po części SQL-owe nie jest wiadome jak zachowuje się w zw. z mirroringiem.
*4. Nie można określić korzyści wyrażonej w zasobach i wydajności*,
5. Migracja wymaga narzędzi.

Pozostaje obalić, lub potwierdzić te punkty :)

Jak na razie brakuje mi jasnego uzasadnienia w jakim celu stosować to rozwiązanie.

P.S.
15.000 $ per Web Serwer to fura pieniędzy

Maćku
Spróbuj proszę załadować do SharePointa plik powiedzmy kilkanaście, lub kilkadziesiąt mega i co ?
Masz time-out czy udało się go włożyć? Do tego dołóż sobie wersjonowanie takich plików. Co z tego wynika?

Tak - to prawda: zastosowanie RBS/EBS Komplikuje strategię disaster recovery, bo rezygnujemy ze
Standardu.
Tak - to prawda że nie są to rozwiązanie tanie, ale kto powiedział że będzie tanio ?

Wpisz w przeglądarce frazę 'keep the sharepoint Content database under' i poczytaj opinie ludzi : np.
„sharepoint 2010 was to store the docs in SQL but to keep the Content database under 100 gig or else you will have problems….” . Czasem zmieni się wielkosć po 'under' ale raczej nie będą to terrabajty.
Co nieco na temat tzw dobrych praktyk w temacie SharePoint Storagehttp://www.scribd.com/doc/25523663/Share-Point-Storage...

W przypadku stosowania SPS nie bardzo mamy wyjście, jeśli mamy potrzebę obsłużenia naprawdę dużych ilosci + wielkości plików + ich wersji. Do tego istnieją odpowiednie i takież drogie rozwiązania dedykowane soft and hard np
http://www.stealthsoftware.co/ + EMC Centera http://www.emc.com/about/news/press/2010/20100512-01.htm

Tak - mój przypadek nie jest reprezentatywny, mogłem sobie pozwolić na luksus 'all-in-one'
itd, itd
Prawdziwy problem jest gdzie indziej. Jestem przekonany że trzeba zadać sobie/użytkownikom pytanie :
czy SharePoint jest aby na pewno odpowiednim środowiskiem do zastosowań składowania tysięcy istotnie dużych plików? A to już zupełnie inna bajka .....
Na koniec - piszesz:
"Wybacz, że tego tyle jest, ale mnie temat bardzo interesuje, a nie mam czasu by go całkowicie przebadac samodzielnie"
Prawda jest taka, że nie ma innej drogi jak przebadać to samodzielnie. Nie będę zatem tu niczego obalał ani potwierdzał. Myslę że podałem wystarczająco informacji + źródeł w temacie i niniejszym zamykam swoje wywody w tej kwestii, bo inaczej trzeba by konferencję zorganizować ;-)Tadeusz Szczygielski edytował(a) ten post dnia 10.02.11 o godzinie 14:34

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Może taka konferencja by się właśnie przydała? :)

Same timeouty to nie wina SharePoint, czy ładowania ich do SQL a wynik konfiguracji obu i IIS. Można tym manipulować. Pytanie czy to ma sens?

Tu dochodzimy do pytania, które słusznie zdałeś. Czy do tego służy SharePoint? Jeśli nie, to po co w nim coś takiego, jeśli tak to dlaczego jest tyle zabawy i niewiadomych związanych z użyciem takiej techniki?

Ale to już dyskusja na konferencję właśnie.

A jeszcze co do opinii różnych, co do wydajności. Z jednej strony widziałem 600+ GB śmigające jak złoto, a z drugiej zdychające 100 GB. Jednak gdy człowiek przypatrzył się sprzętowi, infrastrukturze i podobnym zagadnieniom. To stawało się jasne, dlaczego w jednej sytuacji działa a w drugiej nie.

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

Maciej Raczyński:
Może taka konferencja by się właśnie przydała? :)

Same timeouty to nie wina SharePoint, czy ładowania ich do SQL a wynik konfiguracji obu i IIS. Można tym manipulować. Pytanie czy to ma sens?

Tu dochodzimy do pytania, które słusznie zdałeś. Czy do tego służy SharePoint? Jeśli nie, to po co w nim coś takiego, jeśli tak to dlaczego jest tyle zabawy i niewiadomych związanych z użyciem takiej techniki?

Ale to już dyskusja na konferencję właśnie.

A jeszcze co do opinii różnych, co do wydajności. Z jednej strony widziałem 600+ GB śmigające jak złoto, a z drugiej zdychające 100 GB. Jednak gdy człowiek przypatrzył się sprzętowi, infrastrukturze i podobnym zagadnieniom. To stawało się jasne, dlaczego w jednej sytuacji działa a w drugiej nie.

Zgłosiłem temat do konferencji http://www.timeforsharepoint.pl/ kto wie może się załapie ?

Temat: Dokumenty z SharePointa na serwerze plików a nie w SQL

deleteKrzysztof Maczyński edytował(a) ten post dnia 24.02.11 o godzinie 11:21