Wydajność i redundancja BPS. Paweł Jawień, WEBCON

Transkrypt

1 Wydajność i redundancja BPS Paweł Jawień, WEBCON

2 Agenda prezentacji Część I Przypomnienie architektury BPS Część II Elementy do optymalizacji Część III Propozycje optymalizacji Część IV Monitoring podstawą optymalizacji Czesc V Wysoka dostepnosc systemu WEBCON BPS

3 Architektura WEBCON BPS WEBCON BPS SOLUTION ARCHITECTURE DIAGRAM REST webservices ios, ANDROID, WINDOWS 8 / PHONE WORD, OUTLOOK SQL WEBCON BPS SHAREPOINT FEATURE WEBCON BPS WINDOWS SERVICE SHAREPOINT DATABASES WEBCON BPS DATABASES WEBCON BPS Designer Studio HTTP - HTTPS INTERNET EXPLORER External system connections http/https/smtp/ldap/ldaps/sql CONNECTIVITY SCANNERS TWAIN FILE SHARE TCP MS LYNC TCP 5061 MAIL SERVER SMTP, EWS WEBSERVICES.NET, SOAP, REST ACTIVE DIRECTORY LDAP, LDAPS DATABASE LEVEL MS SQL TCP 1521, ORACLE TCP 1433

4 Część II Elementy do optymalizacji W kolejności wg. Wagi problemu: 1. Server SQL baza danych 2. Zewnętrzne źródła danych 3. Serwer Sharepoint 4. Filtry na SWE 5. WEBCON BPS architektura systemu (nie będzie omawiana) 6. WEBCON BPS projekt obiegów (nie będzie omawiane)

5 Serwer SQL - zalecenia Wydajność WEBCON BPS, a także SHAREPOINT zależy w 90% od wydajności SQL Wydajność SQL w 60% może zależeć od przygotowania platformy sprzętowej. Sprzęt na co zwrócić uwagę: 1. Dyski 2. Dyski 3. Dyski 4. Pamięć 5. Procesor The highest ranked item should be in the fastest drives. tempdb data files and transaction logs Content database transaction log files Search databases, except for the Search administration database Content database data files

6 SQL dyski: ilość, jakość, konfiguracja Nie istnieje dla nas RAID5 (generuje dwukrotnie większą ilość I/O) (Tylko RAID10) Chyba, że. Używamy dysków SDD (SERWEROWYCH) Przechowujemy na RAID5 tylko bazy załączników Ile? Dysków nigdy nie jest zbyt dużo. Dużo głowic, szybszy dostęp. Warto zaplanować podział bazy na pliki (nawet wówczas, gdy jeszcze nie mamy dysków. Monitorujemy (Avg. Disc Queue lenght)

7 SQL pamięć i procesor Ile pamięci RAM powinien mieć SQL? Ile się da zabierze każdą ilość Zalecenie wielu audytorów SQL to RAM = 1/3 wielkości bazy danych Ile pamięci Wirtualnej? 1 x RAM? 1,5 x RAM? Crush dump file size? A może 0? RAM JEST TANI!!!

8 SQL pamięć i procesor Nie ma jednej odpowiedzi trzeba monitorować Podstawowe miary \Memory\Page/sec (40-150) \Memory\Page Reads/sec \Memory\Page Inputs/sec Procesor WEBCON BPS nie ma wielkich wymagań co do stosowanego procesora (wyjątkiem jest OCR). Ważny jest monitoring jeżeli średnie obciążenie procesora nie przekarcza 70%, nic nie zmieniamy.

9 Maintance plans, monitoring działań wsadowych Maintance plan Reindeksacja baz - warto użyć skryptów sprawdzających stopień fragmentacji i dopiero wówczas realizować reorganizację lub rebuild indeksów. Optymalnie codziennie Przebudowa statystyk raz w tygodniu Weryfikacja wszelkich działań wsadowych: Backup (Full backup) w okienku serwisowym Subskybcje dużych raportów w okienku serwisowym Exporty/importy danych w okienku serwisowym

10 Monitoring obciążenia! Obowiązkowe trzy liczniki: Processor Time max. 75% Memory\Pages\sec max. 150 Avg. Disc Queue lenght max. 2 (0.5 alert)

11 Wirtualizacja Wirtualizacja jest dobra (jest konieczna) ale 4 x 4 16 Monitorując liczniki maszyny wirtualnej, nie monitorujemy fizycznych parametrów Hosta! Host również zużywa zasoby!!!! NIGDY NIE UŻYWAMY DYSKÓW WIRTUALYCH DLA SQL!!!

12 Wysoka dostępność systemu WEBCON BPS Wracamy do architektury BPS Trzy składniki do zabezpieczania: Sharepoint 1 Loadbalancer Sharepoint 2 Bazy SQL Witryny SHAREPOINT WEBCON BPS Service Do wersji 7.7 BPS pozostawał jeden element bez redundancji: WEBCON BPS Service. Wersja 8.0.x wypełnia ten brak WEBCON BPS Service SQL 1 SQL 2 Shared storage WEBCON BPS Service Minimalne środowisko redundantne

13 Wysoka dostępność systemu WEBCON BPS O co walczymy? Acceptable availability percentage Downtime per day Downtime per month Downtime per year 90 (one nine) minutes 72 hours 36.5days 99 (two nines) minutes 7 hours 3.65 days 99.9 (three nines) seconds 43 minutes 8.77 hours (four nines) 8.64 seconds 4 minutes minutes (five nines) 0.86 seconds 26 seconds 5.26 minutes

14 Wysoka dostępność SQL Metody zapewnienia wysokiej dostępności: AlwaysOn Failover Cluster Instances AlwaysOn Availability Groups (od SQL 2012) Database mirroring (znika w kolejnych wersjach SQL) Log shipping

15 Wysoka dostępność SQL LOG Shipping Plusy dodatnie: Zapewnia rozwiązanie disasterrecovery dla wybranej bazy danych Odporne na uszkodzenia dysków Pozwala na wykorzystanie bazy read-only do celów raportowych Plusy ujemne: Zawsze jest opóźnienie w synchronizacji baz Bazy muszą być w trybie: Full recovery Nie ma automatycznego failover Potencjalnie duży czas przywrócenia dostępności

16 Wysoka dostępność Database mirroring Plusy dodatnie Działa na poziomie bazy danych. W konfiguracji high-safety zapewnia bezstratne, automatyczne przełączanie bazy danych. Odpornośc na uszkodzenia dysków. Minimalizuje downtime podczas upgrade systemu. Instancje mogą znajdować się w odległych lokalizacjach. Plusy ujemne. Tylko jedna instancja zapasowa. Bazy muszą być w trybie: Full Recovery W trybie synchronicznym ma wpływ na wydajność bazy. W trybie asynchronicznym może nastąpić niewielka utrata danych. Nie obsługuje FILESTREAM

17 Wysoka dostępność SQL - Cluster Plusy dodatnie: Działa na poziomie instancji serwera. Całkowicie automatyczne przełączenie. Brak jakiejkolwiek utraty danych przy failover. Nie wymaga duplikacji powierzchni dyskowej. Możliwe automatyczne przełączanie między nodami w momencie wykrycia potencjalnych awarii i/lub wg. harmonogramu SQL node 1 SQL node 2 Shared storage Plusy ujemne: Shared storage potencjalny single point of failure. Konieczność stosowania certyfikowanego sprzętu.

18 Wysoka dostępność SQL Always ON Availability Groups Plusy dodatnie: Eliminuje single point of failure Wiele instancji zapasowych. Jednoczesne działania w różnych trybach (asynchroniczny, synchroniczny) Umożliwia dostęp read-only do repliki danych raportowanie. Aktywności typu backup można realizować na replice. Plusy ujemne: Wymaga powielania wielkości storage. Wymaga stosowania WSFC. Wysoki koszt.

19 Wysoka dostępność - SHAREPOINT Dla zapewnienia wysokiej dostępności systemu WEBCON BPS wystarczy zapewnić wysoką dostępność frontonów Sharepoint (oczywiście zakładając wysoką dostępność bazy danych). Dodając kolejne frontony Sharepoint zwiększamy dostępność i zarazem zapewniamy równoważenie obciążenia. Loadbalancer Fronton 1 Fronton 2 Fronton n Zalecany dedykowany loadbalncer sprzętowy: KEMP, F5, Barracuda - tu też warto rozważyć HA HA Database

20 Wysoka dostępność WEBCON BPS Service WEBCON BPS Service może być instalowany na dowolnym serwerze Windows w sieci (nie musi mieć zainstalowanego Sharepointa). Możemy instalować wiele instancji serwisu. Serwis jest redundantny, ale może również zapewniać loadbalancing Serwis licencji tylko w jednym miejscu. Raportowanie, monitorowanie event log alert

21

22 Dziękuję za uwagę