SQL Server – konsolidace a administrace

1. SQL Server – konsolidace a administrace Michael JuřekSoftware ArchitectMicrosoft s.r.o.

2. Agenda • Proč konsolidovat? • Způsoby konsolidace • Zajištění a monitorování výkonnosti • Hromadná správa • Oddělení infrastruktury od databází • Přechod na SQL 2008 R2

3. Motivace pro konsolidaci • Lepší využití prostředků • Menší spotřeba místa • Menší spotřeba proudu • Efektivnější licencování • Často zároveň HW standardizace • Efektivnější správa • Méně serverů na správu a údržbu • Centralizovaná správa více serverů naráz • Flexibilita využití prostředků • Efektivní rozkládání zátěže • Nižší náklady a jednodušší zajištění vysoké dostupnosti

4. Rizika konsolidace • Pokud se provede špatně, věci se zhorší, ne zlepší • Počet databází neklesne • Na začátku je práce spíše více, klesá až v delším časovém horizontu • Nelze konsolidovat každou databázi, aplikaci, server

5. Agenda • Proč konsolidovat? • Způsoby konsolidace • Zajištění a monitorování výkonnosti • Hromadná správa • Oddělení infrastruktury od databází • Přechod na SQL 2008 R2

6. Konsolidace – základní otázky • Je lépe konsolidovat do jedné instance nebo využívat více instancí? • Čím je možné spravovat a přidělovat HW zdroje? • Jaké jsou možná nebezpečí, pokud budeme konsolidovat databáze do jednoho serveru? • Je možné konsolidovat i SQL databáze pro jiné MS produkty?

7. 1. Jedna instance, více databází • Snížení počtu fyzických serverů • Centralizovaná administrace databázových serverů • Resource Governor pro řízení výkonu a správu zdrojů • Databáze sdílí řadu objektů • Joby, loginy, …

8. 2. Více instancí, jeden server • Snížení počtu fyzických serverů • Centralizovaná administrace databázových serverů • Windows System Resource Monitor pro řízení výkonu a správu zdrojů • Databáze sdílí pouze objekty OS • Účty, soubory apod.

9. 3. Více virtuálních, 1 fyzický server • Snížení počtu fyzických serverů • Oddělení serverových OS • Je možné řešit přidělování zdrojů pro OS na úrovni virtualizační vrstvy • Licence SQL Enterprise – není třeba licencovat SQL Servery ve virtuálních prostředích

10. Porovnání způsobů • Izolace aplikací roste od 1 do 3 • Režie roste od 1 do 3 • Různé prostředky pro řízení výkonu • Různé prostředky pro vysokou dostupnost • Příliš mnoho možností… • … a univerzální postup neexistuje

11. Agenda • Proč konsolidovat? • Způsoby konsolidace • Zajištění a monitorování výkonnosti • Hromadná správa • Oddělení infrastruktury od databází • Přechod na SQL 2008 R2

12. Správa serverových zdrojů

13. Potřeba řízení prostředků • Až do SQL 2005 všechny požadavky v rámci jedné instanci sdílí všechny zdroje: • Problém 1: Nelze garantovat zdroje pro určitý požadavek • Problém 2: Nelze zamezit požadavku, aby vypotřeboval všechny zdroje • SQL 2008 a 2008 R2 přináší řešení...

14. Resource Governor - princip • Resource Pool: • Seskupení zdrojů s nastavenými limity pro CPU a paměť • Workload Group: • Je namapována na jediný resource pool • Jsou jí přiřazena spojení do databáze a veškeré akce na nich prováděné • Pomocí konfigurační funkce klasifikující přicházející spojení • Lze využít jméno uživatele, jméno aplikace, denní dobu, … • Jsou prioritizovány mezi sebou navzájem • Speciální skupiny a pooly default a internal • Vše uvedené výše lze dynamicky měnit • Změny se uplatní při novém databázovém spojení • Monitorování – čítače v System Monitoru

15. Resource Governor

16. Performance Studio • Centralizovanéúložiště dat • Poskytovatelé • SQL Trace • Performance Counters • Transact-SQL • Rozšiřitelné… • Rozšiřitelné, možnostuložení vlastních dat • Sběr dat snízkou režií • Bohatéreportování

17. Architektura sběru dat SSMS msdb SQL Agent SQL Server MDW Data Collector (dcexec.exe) Operačnísystém Cache(soubory)

18. Správa sběru dat • Management Studio • Nakonfigurování databáze datového skladu • Nastavení parametrů setu • Spuštění/zastavení sběru • Manuální vynucení okamžitého sběru • Spuštění připravených reportů • SQL Server Agent • Joby typu collection a upload pro každý set • Používá balíčky pro integraci dat pomocí SSIS uložené v MSDB databázi

19. demo Performance Studio

20. Agenda • Proč konsolidovat? • Způsoby konsolidace • Zajištění a monitorování výkonnosti • Hromadná správa • Oddělení infrastruktury od databází • Přechod na SQL 2008 R2

21. Proč správa pomocí politik? • Automatizace denní rutiny administrátora: • Sledování, zda je vše nastaveno tak jak bylo zamýšleno • Varování v případě odchylky od zamýšlené konfigurace • Oprava případné chyby v konfiguraci • Navíc: Zabránění chybě v konfiguraci • Tohoto cíle se dosáhne prostřednictvím politik • Politiky lze uplatnit na jeden server anebo skupinu serverů v jednom kroku • Politiky jsou trvalé, lidská kontrola je jednorázová

22. Správa pomocí politik • Aspekty • Podmínky • Politiky Cíle Kategorie

23. Postup definice politiky • Vybereme aspekt (facet) • Například databáze, uložená procedura, server, ... • Definujeme podmínky, které mají být splněny • Např. databáze musí mít model obnovy Full • Definujeme podmínky určující cílovou skupinu • Např. všechny uživatelské databáze • Kombinací výše uvedených podmínek vytvoříme politiku: • Nastavíme vysvětlující texty, odkazy • Vybereme režim kontroly: • Manuálně, periodicky se zalogováním porušení, zalogování porušení při změně, zabránění změně (v některých případech) • Povolíme politiku

24. Správa skupin serverů • Dvě možné definice skupin: • Lokální skupina – uložena v nastavení lokálního Management Studia • Serverová skupina – uložena v MSDB na označeném tzv. konfiguračním serveru (musí být Enterprise Edition) • Skupiny lze využít ke: • Spuštění dotazu na více serverech současně • K výsledku se přidá sloupec se jménem serveru • Import politiky na více serverů současně • Typický scénář: odladění na jednom serveru, export, import na více serverů • Vyhodnocení politiky na více serverech současně

25. demo Hromadná správa serverů

26. Agenda • Proč konsolidovat? • Způsoby konsolidace • Zajištění a monitorování výkonnosti • Hromadná správa • Oddělení infrastruktury od databází • Přechod na SQL 2008 R2

27. Vize – databázová samoobsluha • Pro aplikace 2. třídy (ne např. SAP), kterých je více a které nevyžadují každodenní péči • IT dodává databázovou infrastrukturu (database utility) a nastavuje zabezpečení, pravidla a politiky • Vlastníci databází si je vytváří a spravují (podobně jako dnes SharePoint weby) • Symetrie mezi firemní serverovnou a SQL Azure • Vize bude zcela naplněna až v dalších verzích

28. Data-Tier Application • Jednotka nasazení • Definice databázových objektů • Pouze „bezpečné“ objekty bez vlivu na konfiguraci serveru • Základní podmínky nasazení (např. verze SQL) • Podpora pro automatickou aktualizaci schématu při nové verzi • Vytvoření aplikace: • Visual Studio 2010 • Konverze existující databáze • Export existující data-tier aplikace • Nasazení aplikace (*.dacpac souboru): • Management Studio • Skript

29. SQL Server Utility • Budoucí vrstva unifikované infrastruktury • Centrální správa z jedné konzole • Utility Control Point (UCP) – SQL 2008 R2 Enterpise/DataCenter • Managed Instance – SQL 2008 R2 jakýkoliv • Definice politik pro žádoucí spotřebu zdrojů na úrovni databáze a instance • Monitorování nevytížených a přetížených prostředků • Mnohem více funkcí v dalších verzích

30. demo SQL Server Utility

31. Agenda • Proč konsolidovat? • Způsoby konsolidace • Zajištění a monitorování výkonnosti • Hromadná správa • Oddělení infrastruktury od databází • Přechod na SQL 2008 R2

32. Přechod na SQL 2008 R2 • Při konsolidaci bývá žádoucí snížit počet provozovaných databází a jejich verzí • Migrace – přechod z jiného typu databáze • Složitost kolísá mezi triviálním převodem dat a kompletním přepisem celé aplikace • Nástroje pro Oracle, Sybase, MySQL, Access • http://www.microsoft.com/sqlserver/2008/en/us/migration.aspx • Upgrade – přechod mezi verzemi SQL Serveru

33. Upgrade na SQL 2008 R2 • SQL Server 2000 – startovní bod • 2000 -> 2005 • Velké množství změn v DB stroji • Některé části verze 2000 označeny „deprecated“ • 2005 -> 2008 • Inkrementální, zpravidla bezproblémové změny • Některé části verze 2000 zcela odstraněny • 2008 -> 2008 R2 • Žádné podstatné změny v DB stroji

34. Přístupy k upgradu • Úroveň 0 – pomodlím se a upgraduji • Kupodivu funguje poměrně dobře • Úroveň 1 – analýza dopadu upgradu • Adekvátní pro většinu řešení • Úroveň 2 – komplexní testování kompatibility • Pro nejnáročnější scénáře • Dodavatel provede za vás 

35. Postupy upgradu

36. In-Place

37. Side-by-side

38. Upgrade Advisor • Analyzuje • Konfiguraci, databázové objekty a komponenty instance • Soubory zachycené profilerem (z živého provozu) • Libovolný T-SQL skript • Generuje zprávu • Věci, které je nutno vyřešit před upgradem • Věci, které je nutno nastavit po skončení upgradu • Kritické věci, které znemožňují upgrade • Doporučení a poznámky

39. demo Upgrade Advisor

40. Application Compatibility Testing (ACT) • Nástroj vyvinutý produktovým týmem SQL a firmou Scalability Experts • Expertní nástroj pro nejnáročnější a nejdůležitější aplikace • Soustředí se na výkonnostní charakteristiku aplikace před a po provedení upgradu • Primárně slouží k porovnání výkonnosti dvou systémů: • Pro 2 různé hardwarové konfigurace • Pro 2 verze SQL serveru apod.

41. Expertní nástroje – ACT Production Test Database Upgrade Trace File Replay (pre-upgrade) Comparison Reports Replay (post-upgrade) Capture

42. Shrnutí • Konsolidace má mnoho pozitivních přínosů • Konsolidace vyžaduje výběr ze široké palety možností, každá je unikátní • Důležité je nepodcenit zajištění a monitorování výkonnosti • V každé verzi SQL serveru je více technologií pro hromadnou správu • Trend do budoucna je oddělení databází od databázové infrastruktury a s ní spojené rozdělení odpovědností