GoldenLine
Zaloguj się
Leszek Biskupski

Leszek Biskupski menedżer zespołu
systemów Microsoft

Temat: BO XI 3.1 Failover

Czy mógłby ktoś podpowiedzieć jakie w BO XI 3.1 są możliwości zbudowania rozwiązania uodpornienia produkcji na awarię.

Chodzi o przypadek utraty serwera.
Jak skonfigurować serwer zapasowy tak aby jak najszybciej można było odtworzyć/kontynuować produkcję "na boku" ?
Link do wypowiedziLink
Krzysztof Jackiewicz

Krzysztof Jackiewicz Business Objects
Expert

Temat: BO XI 3.1 Failover

Proponuję zbudowanie klastra aktywno-pasywnego. Na pasywnym węźle (oddzielna, identyczna maszyna jak dla węzła aktywnego) instalujemy te same usługi co na węźle aktywnym, konfigurujemy, parametryzujemy, tworzymy połączenia do baz raportowych w identyczny sposób jak na aktywnym.
Oczywiście pliki Input i Output FRS umieszczamy gdzieś na współdzielonym zasobie a nie na maszynie jednego lub drugiego węzła. W momencie awarii nie tracimy ich, podobnie jak nie tracimy bazodanowych zasobów repozytorium. Klaster zapewnia nam spójność.
W momencie utraty aktywnego węzła, uruchamiamy usługi na węźle pasywnym. No i w przypadku posiadania licencji procesorowej, mając klaster aktywno-pasywny, nie naruszamy warunków licencji, ponieważ w jednym czasie używamy tylko określonej liczby procesorów na które mamy licencje.
Link do wypowiedziLink

konto usunięte

Temat: BO XI 3.1 Failover

Krzysztof Jackiewicz:
Proponuję zbudowanie klastra aktywno-pasywnego. Na pasywnym węźle (oddzielna, identyczna maszyna jak dla węzła aktywnego) instalujemy te same usługi co na węźle aktywnym, konfigurujemy, parametryzujemy, tworzymy połączenia do baz raportowych w identyczny sposób jak na aktywnym.
Oczywiście pliki Input i Output FRS umieszczamy gdzieś na współdzielonym zasobie a nie na maszynie jednego lub drugiego węzła. W momencie awarii nie tracimy ich, podobnie jak nie tracimy bazodanowych zasobów repozytorium. Klaster zapewnia nam spójność.
W momencie utraty aktywnego węzła, uruchamiamy usługi na węźle pasywnym. No i w przypadku posiadania licencji procesorowej, mając klaster aktywno-pasywny, nie naruszamy warunków licencji, ponieważ w jednym czasie używamy tylko określonej liczby procesorów na które mamy licencje.

Widać że kolega zna się na rzeczy. Również polecam takie rozwiązanie.
Dodam tylko że serwer www można postawić na trzeciej maszynie aby dodatkowo podnieść niezawodność i wydajność lub zastosować load balancer, który automatycznie przerzuci ruch na zapasową maszynę w przypadku padnięcia maszyny głównej.Przemysław Kapica edytował(a) ten post dnia 28.07.10 o godzinie 18:16
Link do wypowiedziLink

konto usunięte

Temat: BO XI 3.1 Failover

W linku przykładowe rozwiązanie wypasionego clustra Business Objects.

"http://bp0.blogger.com/_0wJ7ht_9awo/R52V-ndrgpI/AAAAAAAAARw/YfBfnzW5kcY/s1600-h/Standard+Business+Objects+XI+R2+Cluster+Sample+Architecture.jpg"Przemysław Kapica edytował(a) ten post dnia 28.07.10 o godzinie 18:57
Link do wypowiedziLink
Leszek Biskupski

Leszek Biskupski menedżer zespołu
systemów Microsoft

Temat: BO XI 3.1 Failover

Dziękuję koledzy za tak szybką i rzeczową odpowiedź.

Chciałbym jednak uściślić. Czy mówimy o klastrze systemowym (Windows) czy jakimś autorskim rozwiązaniu SAP BO ?

Widziałem, że można łączyć na poziomie BO maszyny i stawiać na nich dowolną ilość serwerów (BO) ale nie wiem czy to idzie w kierunku load balancing czy też niezawodności i na ile jest to przydatne w takim zastosowaniu jak ja potrzebuje?

Szczerze powiedziawszy chciałbym to zrobić jak najmniejszym kosztem (BO nie jest w tej chwili strategiczne). Myślałem o czymś na wzór mirrora (2 serwer na Virtualu)
Link do wypowiedziLink
Krzysztof Jackiewicz

Krzysztof Jackiewicz Business Objects
Expert

Temat: BO XI 3.1 Failover

Chyba obaj mieliśmy na myśli klaster w wydaniu Business Objects. Na jednej maszynie mamy włączone usługi BO, na drugiej maszynie - wyłączone. Drugi serwer BO oczywiście może działać na maszynie wirtualnej, która ma przypisane minimum zasobów, a dopiero w momencie awarii dostaje odpowiednią ilość CPU czy RAMu.
To co łączy aktywny serwer BO z pasywnym, który w każdej chwili może stać się aktywnym (podczas awarii), to repozytoium BO, które składa się z tabel w bazie relacyjnej oraz systemu plików. I te zasoby powinny być wspólne dla obydwu serwerów-węzłów BO.
Klasyczny klaster w wydaniu BO oczywiście służy zarówno do load balancingu, jak i zapewnienia niezawodności.
Możliwa jest również konfiguracja Business Objects na klasycznym klastre Windowsowym.
Link do wypowiedziLink
Leszek Biskupski

Leszek Biskupski menedżer zespołu
systemów Microsoft

Temat: BO XI 3.1 Failover

I ponownie zrobiło się jaśniej :).
Skupię się na rozwiązaniu z "budżetową" maszyna na VM.
Repozytorium można by załatwić przy pomocy MS SQL 2005 mirroring (co o tym sądzicie ? sprawdzi się ?). Wtedy podczas awarii 2 serwer będzie miał u siebie aktualne repozytorium. Natomiast nie wiem jeszcze jak rozwiązać problem z FRS(IN, OUT) ono zdaje się też musi być współdzielone (czy się mylę?) i na domiar złego spójne ze repozytorium.
To z tym począć, żeby nie kupować macierzy ?
Link do wypowiedziLink

konto usunięte

Temat: BO XI 3.1 Failover

Cluster BO polega na tym że obydwa serwery CMS podłączone są do tej samej bazy repozytorium. Nie zajmowałem się mirroringiem na SQL 2005 ale obawiam się że będą problemy ze stworzeniem takiego clustra poneiważ każdy CMS będzie miał osobną bazę. Najlepszym rozwiązaniem jest postawić bazę repozytorium na osobnej maszynie. Baza nie jest duża więc może znajdzie się gdzieś w firmie jakiś serwer z zainstalowanym SQL Serverem.

CO do FRS to najlepiej użyć macierz ale ponieważ będzie to cluster aktywno-pasywny więc w jednym czasie tylko serwery z jednej maszyny będą wykonywały operacje zapisu i odczytu. Wystarczy więc zasób sieciowy na osobnej maszynie (oczywiście również odpowiednio zabezpieczonej na wypadek awarii).

Czy kolega Krzysztof zgodzi się ze mną? :)Przemysław Kapica edytował(a) ten post dnia 29.07.10 o godzinie 08:24
Link do wypowiedziLink
Krzysztof Jackiewicz

Krzysztof Jackiewicz Business Objects
Expert

Temat: BO XI 3.1 Failover

Lepiej bym tego nie napisał :)
Nigdy nie eksperymentowałem z repozytorium na mirrorowanej bazie danych, nie spotkałem się też z podobnym wdrożeniem. Chyba znacznie bezpieczeniejsze z punktu widzenia zapewnienia spójności repozytorium jest utrzymanie pojedynczej bazy i systemu plików FRS.
Link do wypowiedziLink
Leszek Biskupski

Leszek Biskupski menedżer zespołu
systemów Microsoft

Temat: BO XI 3.1 Failover

Wydaje mi się, że mirror powinien zdać tutaj egzamin ponieważ z tego co widziałem połączenie BO z repozytorium można zdefiniować przez ODBC a to z kolei można oprzeć na kliencie MS SQL, który wspiera mirror i generalnie BO będzie łączyło się z aktualnie dostępnym serwerem nawet o tym nie wiedząc.

Co do FRS jednak nie wiem jak będzie wyglądała wydajność przy pracy z udziałem sieciowym. Z waszego doświadczenia jak to wychodzi ?
Gdzie można spodziewać się wąskiego gardła w BO ?
Link do wypowiedziLink
Krzysztof Jackiewicz

Krzysztof Jackiewicz Business Objects
Expert

Temat: BO XI 3.1 Failover

Co do mirroringu bazy - cóż, wymagałoby to przetestowania. Czuję, że takie rozwiązanie może nie być wspierane przez producenta BO, jeśli to ma jakiekolwiek znaczenie - ale warto się dowiedzieć.
A co do FRS - pracuję z dużym środowiskiem (kilkuset użytkowników, tysiące raportów), mój klaster aktywno-pasywny używa po prostu zwykłych kart 1Gb do komunikacji z udziałem sieciowym i absolutnie nie jest to wąskie gardło.
Wąskie gardła w BO ? Wszystko zależy od ilości użytkowników i stopnia wykorzystania platformy raportowej - wąskim gardłem może być serwer aplikacji/www obsługujący BO, zbyt niskie parametry serwisów BO no i oczywiście sprzęt - CPU, RAM...
Link do wypowiedziLink

konto usunięte

Temat: BO XI 3.1 Failover

Jeśli przyjrzysz się wielkości plików przechowywanych w File Storze to zobaczysz, że są one bardzo małe (wyjątkiem mogą być pliki zewnętrze np. xls, doc, itp których rozmiar zależy już wyłącznie od użytkowników). Nie martwiłbym się więc o wydajność takiego zasobu.

Wąskie gardła - tu odsyłam do Sizing Guide. Z doświadczenia mogę powiedzieć że przy około 200 jednocześnie aktywnych użytkowników sam Tomcat może zarezerwować sobie ponad 700MB RAM. Do tego WebIntelligence Report Server 200MB i już prawie 1GB RAM z głowy.

Wszystko jednak zależy od tego jakie operacje użytkownicy będą wykonywać w systemie. Uruchamianie gotowych raportów jest znacznie mniej zasobożerne od ich tworzenia (tu również z doświadczenia posłużę się przykładem, kiedy użytkownicy generowali raporty, które po zapisaniu w XLS zajmowały 40MB).

W praniu wyjdzie czy czas oczekiwania na raport będzie generowany przez BO czy hurtownię. Zazwyczaj jest tak że to BO czeka na dane zwracane przez hurtownię danych.
Link do wypowiedziLink
Leszek Biskupski

Leszek Biskupski menedżer zespołu
systemów Microsoft

Temat: BO XI 3.1 Failover

Dziękuję wam koledzy naprawdę bardzo mi pomogliście.
Wypracowanie koncepcji to już duży kawał roboty a dzięki wam można powiedzieć, że jest już za mną.

Teraz muszę wpisać ją w naszą infrastrukturę i przygotować się do realizacji ale to już inna para kaloszy.
Link do wypowiedziLink
Monika Bielawska

Monika Bielawska SAP BusinessObjects
Expert Consultant

Temat: BO XI 3.1 Failover

Koledzy sie super spisali to ja juz tylko dodam link do dokumentacji:
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid...
Link do wypowiedziLink
Marcin Nowok

Marcin Nowok Konsultant Business
Intelligence -
Freelancer/praca
zdalna

Temat: BO XI 3.1 Failover

Wyłoniły nam się dwa podejścia do zagadnienia:
1. Backup/disaster recovery - link Moniki
2. Failover - propozycja Krzyśka i Przemka

Musisz sam teraz dobrać najbardziej pasujące rozwiązanie. W przypadku backupu odpada część problemów z infrastrukturą, macierzą, mirrorowaniem bazy itd. Trzeba natomiast te backupy robić. W przypadku failoveru (mam na mysli pełny klaster na wszystkich poziomach - BO, web serwer, baza danych i macierz) bedziesz miał znacznie więcej pracy na początku, ale za to potem działa to prawie automatycznie. Zwróć uwagę na wykorzystanie BO w Twojej firmie - czy jest to lub będzie kluczowa aplikacja z dużą ilością użytkowników, raportów, akcji typu odświeżanie, schedulowanie, zapisywanie do pliku (np. xls), itd. Jeśli tak to failover będzie zdecydowanie lepszym rozwiązaniem. W przeciwnym przypadku sugerowałbym backupy (i oczywiscie dodatkowa pasywna instancja na VM).

Wąskie gardła - staraj się unikać raportów Desktop Intelligence. Potrafią mocno konsumować zasoby systemowe (ponadto w nastepnej wersji BO nie będą już wspierane).
Link do wypowiedziLink
Tomasz Sawczuk

Tomasz Sawczuk Senior Consultant,
SAP Polska

Temat: BO XI 3.1 Failover

Nie rozumiem co ma backup/recovery do failover?
Backup nie służy przecierz tylko do tego aby obsłużyć awarię sprzętową.
Backup/Recovery to konieczność, nie zależnie od spraw związanych z zachowaniem dostępności rozwiązania.

Pozdrawiam
Link do wypowiedziLink
Marcin Nowok

Marcin Nowok Konsultant Business
Intelligence -
Freelancer/praca
zdalna

Temat: BO XI 3.1 Failover

Zgadzam się, że backup jest koniecznością, tutaj chyba nie ma wątpliwości. Jednak w przypadku gdy system nie jest krytyczny wtedy utrzymywanie pełnego failoveru może nie mieć uzasadnienia ani biznesowego ani kosztowego. Oczywiście, że failover jest wygodnym rozwiązaniem i wszystko pięknie działa - ale i kosztuje. Backup (konieczny) może sie jednak okazać wystarczającym rozwiązaniem obsługującym awarie.

Pozdrawiam
Link do wypowiedziLink
Monika Bielawska

Monika Bielawska SAP BusinessObjects
Expert Consultant

Temat: BO XI 3.1 Failover

No wlasnie wydawalo mi sie, ze moi poprzednicy na tyle wyczerpujaco opisali kwestie clusteringu, ze chcialam dodac jeszcze alternatywe ze wzgledow opisanych przez Marcina ale zeby zadoscuczynic wszystkim :-)dodaje jeszcze info o dokumentacji dotyczacej clusteringu samego w sobie:
wchodzimy na strone http://help.sap.com/ i tam wybieramy zakladke SAP BusinessObjects -> All Products
a nastepnie z list rozwijanych produkt BusinessObjects Enterprise i podrecznik
SAP BusinessObjects Enterprise Deployment Planning Guide (* wymaga loginu)
mysle, ze teraz juz wilk bedzie syty i owca cala ;-)Monika Bielawska edytował(a) ten post dnia 05.08.10 o godzinie 17:17
Link do wypowiedziLink

konto usunięte

Temat: BO XI 3.1 Failover

Monika Bielawska:
Koledzy sie super spisali to ja juz tylko dodam link do dokumentacji:
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid...

Zasługa dobrego nauczyciela ;)
Link do wypowiedziLink
Monika Bielawska

Monika Bielawska SAP BusinessObjects
Expert Consultant

Temat: BO XI 3.1 Failover

Dzieki :)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Loadbalancing i failover po...




Wyślij zaproszenie do
Anuluj