Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



25.02.2020

Koszty w górę

Zmiany w licencjach VMware
24.02.2020

VPN na nowo

WireGuard w Linuksie
24.02.2020

Wydajność pod kontrolą

Citrix Analytics for Performance
24.02.2020

Zaawansowany backup

Veeam Availability Suite v10
20.02.2020

Serwery Enterprise

OVHCloud stawia na Ryzeny
20.02.2020

Monitory dla biznesu

Newline IP
20.02.2020

Przemysłowe SSD

Dyski Transcend M.2 NVMe
23.01.2020

Google Project Zero

Inicjatywa Google Project Zero
23.01.2020

Ochrona tylko w chmurze

Kaspersky Security Cloud Free

Database as a Service – zagrożenia w czasach konsolidacji

Data publikacji: 21-04-2015 Autor: Kamil Stawiarski

Żyjemy w czasach, w których słowo „chmura” częściej kojarzy się z usługą IT niż ze zjawiskiem atmosferycznym, a firmy prześcigają się w oferowaniu rozwiązań cloudowych. Oracle nie jest wyjątkiem – w ofercie największego dostawcy baz danych można znaleźć wiele nowych usług i funkcjonalności oferowanych w modelu Database as a Service (DBaaS) i prywatnej chmury.

Omawiając problematykę konsolidacji, warto zwrócić szczególną uwagę na to, jakie środowiska ze sobą konsolidujemy i jak może to wpłynąć na szeroko pojęte bezpieczeństwo infrastruktury IT. W tym kontekście przyjrzyjmy się flagowemu rozwiązaniu Oracle’a – nowej funkcjonalności w bazie 12c, która zupełnie zmienia fizyczną konstrukcję bazy danych z Redwood.

Do tej pory główną cechą wyróżniającą bazy danych Oracle, jak i główną przeszkodą w przesiadce z innych środowisk, była architektura. W przeciwieństwie do np. SQL Server lub PostgreSQL, w serwerze Oracle mieliśmy tylko jedną bazę danych, podzieloną na schematy będące jednocześnie użytkownikami. Począwszy od bazy 12c, Oracle postanowił wprowadzić podział podobny do pozostałych silników bazodanowych – jedną instancję, w której jest wiele baz, a w każdej z nich wiele schematów. Cała zabawa polega na ułatwionym zarządzaniu skonsolidowanymi środowiskami w ramach jednego klastra. Efektem takiego podejścia jest lepsza dystrybucja zasobów pamięci i procesora, ujednolicony backup i odtwarzanie danych oraz łatwiejsza migracja do nowych wersji, polegająca na zwykłym „wyciągnięciu” bazy danych z matczynego kontenera i wpięciu jej do wersji wyższej.

> ORACLE MULTITENANT ARCHITECTURE

Do niedawna, w sytuacji gdy zaistniała potrzeba konsolidacji wielu środowisk Oracle Database w ramach jednej maszyny lub jednego klastra, zawsze pojawiał się problem z obsługą odpowiedniej ilości pamięci. Każda baza danych posiadała własną instancję, a więc własny zasób pamięci współdzielonej, który musiał być zaalokowany tylko i wyłącznie dla niej na poziomie systemu operacyjnego. Zarządzanie takim środowiskiem przysparzało DBA wielu problemów, zwłaszcza w obrębie priorytetyzacji poszczególnych baz i dobrania odpowiednich rozmiarów SGA dla systemów działających obok siebie.

Skąd w ogóle potrzeba konsolidacji? Przede wszystkim ze względów kosztowych – jeśli instytucja posiada 50 systemów opartych na bazie Oracle, ciężko jest utrzymywać 50 odrębnych serwerów. W takiej sytuacji architekci staną przed wyborem wirtualizacji lub budowy klastra RAC, na który zostaną zmigrowane wszystkie używane bazy danych. Wspomniane rozwiązania nie pozwalają jednak na oszczędność zasobów i łatwe dodawanie kolejnych systemów do istniejącej infrastruktury. Oracle rozwiązał te problemy, zmieniając architekturę bazy danych w taki sposób, aby było możliwe dodawanie nowych tzw. wtyczkowych baz danych (pluggable databases) do kontenera, czyli istniejącej instalacji Oracle’a, która może być stworzona jako np. Real Application Cluster, z zaimplementowaną polityką backupu i rozwiązaniem HA w postaci Oracle Data Guard. Dzięki temu konsolidacja nowych środowisk bazodanowych stała się niezwykle prosta, a do jej częstego wykorzystywania przekonują następujące argumenty:

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"