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



23.06.2020

PLNOG Online

PLNOG Online
23.06.2020

Nowe zagrożenie

Ramsay
23.06.2020

Chmurowe kopie

Veeam Backup dla Microsoft Azure
19.06.2020

Nowości w kontenerach

Red Hat OpenShift 4.4
19.06.2020

Analityka bezpieczeństwa

FortiAI
19.06.2020

UPS dla obliczeń edge

Schneider APC Smart-UPS
16.06.2020

Przemysłowe SD

Nowe karty Transcend
16.06.2020

Storage dla SMB

QNAP TS-451DeU
16.06.2020

Pamięć masowa

Dell EMC PowerStore

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"