Transcript Hromadná správa

SQL Server – konsolidace a
administrace
Michael Juřek
Software Architect
Microsoft s.r.o.
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
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
Ease of
Managemen
t
21%
Reduced
Licensing
Costs
18%
Power
Savings
18%
Higher util
and lower
h/w costs
Rack Space
25%
Savings
• 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
18%
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
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
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?
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, …
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.
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
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
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
Správa serverových zdrojů
Nástroj
Hardware
Partitioning
Vhodný pro… Řešení s
vysokými
nároky na
aplikace
Kompletní
izolace aplikací
Limity…
Není flexibilní,
znamená změny
na úrovni HW
(restart)
Virtuální OS
WSRM
Resource
Governor
Nižší nároky na
výkon aplikace
Nastavení
zdrojů pro
jednotlivé
instance
Nastavení
prostředků CPU
a paměti na
různých
úrovních v rámci
SQL Serveru
Oddělení
operačních
systémů
Částečná
degradace
výkonu
Limit 4
procesory ve
virtuálním stroji
Scénáře s více
instancemi
Nastavení limitů
procesoru
Nastavení limitů
paměti
Neumí IO
operace
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í...
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
Resource Governor
Performance Studio
Poskytovatelé
SQL Trace
Performance Counters
Transact-SQL
Rozšiřitelné…
Sběr dat s
nízkou režií
Centralizované
úložiště dat
Rozšiřitelné, možnost
uložení vlastních dat
Bohaté
reportování
Architektura sběru dat
SSMS
msdb
SQL Agent
SQL Server
Operační
systém
Data
Collector
(dcexec.exe)
Cache
(soubory)
MDW
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
demo
Performance Studio
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
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á
Správa pomocí politik
Aspekty
Podmínky
Politiky
Cíle
Kategorie
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
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ě
demo
Hromadná správa serverů
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
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
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
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
demo
SQL Server Utility
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
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
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
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 
Postupy upgradu
Side-by-Side
Plusy
In-Place
• Krátká odstávka
• Relativně snadná cesta zpět
• Téměr automatické
• Málo práce
Minusy
• Více práce
• Vyžaduje více hardware
• Často delší odstávka
• Obtížná cesta zpět
Vhodné
pro
Kritické aplikace
Menší aplikace
In-Place
Plusy
• Snadná, téměř plně
automatická
• Rychlý proces
• Nevyžaduje dodatečný
hardware
• Nevyžaduje úpravu
aplikací (změna jména
serveru)
Minusy
• Méně kontroly nad
procesem
• Všechny databáze musí
být upgradovány
najednou
• Během upgradu je
databáze nedostupná
• Složitá cesta zpět
Side-by-side
Plusy
Minusy
• Více kontroly nad
procesem
• Lze provést testovací
migraci
• Možnost paralelního běhu
pro testování a verifikaci
• Relativně snadná cesta
zpět
• Zpravidla vyžaduje
dodatečný hardware
• Nutnost zásahu do aplikací
(změna jména serveru)
• Není praktická pro velmi
velké databáze
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
demo
Upgrade Advisor
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.
Expertní nástroje – ACT
Production
Test
Database
Upgrade
Capture
Replay
(pre-upgrade)
Replay
(post-upgrade)
Comparison
Reports
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í