Rozmawiałem z kilkoma administratorami baz danych Oracle i powiedzieli, że istnieje komponent o nazwie Oracle Listener ( http://docs.oracle.com/cd/B19306_01/server.102/b14196/network.htm ), który umożliwia filtrowanie ruchu sieciowego do bazy danych, na przykład gdy komputer wiele interfejsów sieciowych.

Czy w DB2 jest jakieś podobne narzędzie? lub jak mogę to zrobić? ponieważ mogę po prostu skonfigurować jeden port na instancję i to wszystko. Jeśli chcę skonfigurować więcej, muszę to zrobić przez IPTables zapory. Nie mogę jednak skonfigurować, którzy użytkownicy, aplikacje lub obciążenia mają łączyć się z którym interfejsem sieciowym.

1
AngocA 1 marzec 2012, 00:44

2 odpowiedzi

Najlepsza odpowiedź

Serwer bazy danych generalnie nie jest dobrym miejscem do wdrażania i zarządzania skomplikowanym schematem sieciowym. Z punktu widzenia procesora lepiej byłoby delegować tę odpowiedzialność na bardziej wyspecjalizowany sprzęt (przełączniki, routery, zapory itp.) i zamiast tego oszczędzać cenne cykle procesora na potrzeby przetwarzania zapytań do bazy danych. Uruchomienie prostej, nieskomplikowanej konfiguracji sieciowej na serwerze bazy danych ułatwi również zabezpieczenie baz danych, ponieważ mniej administratorów będzie wymagało uprawnień administratora na serwerze bazy danych, gdy nie będzie to wymagało regularnej uwagi ze strony administratorów sieci.

Chociaż instancja DB2 nasłuchuje tylko na jednym porcie TCP (określonym przez DBA), będzie nasłuchiwać na tym porcie na wielu kartach sieciowych i na wielu adresach IP zdefiniowanych na tych kartach. Instancja będzie również nasłuchiwać w innych protokołach sieciowych określonych za pomocą zmiennej rejestru DB2COMM. Na poziomie konfiguracji DB2 nic nie kontroluje, które lokalne karty sieciowe i/lub adresy IP mogą akceptować przychodzące żądania połączeń DB2. Jednak gdy taka szczegółowość jest potrzebna, najlepiej jest obsługiwać ją z dedykowanego firewalla lub routera, a nie z kopii iptables działającej lokalnie.

Nie widzę powodu, dla którego polityka DB2 dotycząca jednego numeru portu TCP na instancję DB2 powinna być traktowana jako ograniczenie. Nawet gdyby DB2 na to pozwolił (lub dałby się na to nabrać), nasłuchiwanie na dodatkowych portach nie przyspieszyłoby czasu odpowiedzi w celu ustanowienia połączenia z bazą danych ani nie zapewniłoby instancji większej przepustowości niż dotychczas. Zwiększenie liczby agentów/wątków zmieniłoby charakterystykę wydajności, ale żadne z tych działań nie wymaga, aby instancja nasłuchiwała na więcej niż jednym porcie TCP. Pomogłoby, gdybym zrozumiał naturę twojego obecnego (lub przewidywanego) problemu, który wynika z tej polityki.

Jeśli niektóre z twoich pytań są oparte na obawach, że karta sieciowa jest pojedynczym punktem awarii, możesz zainteresować się łączeniem sieci Ethernet, które tworzy wrażenie pojedynczej logicznej karty sieciowej z pary fizycznych kart sieciowych. Jest to obsługiwane przez funkcje sieciowe systemu operacyjnego, skutecznie ukrywając złożoność przed serwerami baz danych i innymi aplikacjami sieciowymi.

Karty sieciowe w większości serwerów działają teraz z szybkością gigabitową lub większą, co prawie całkowicie eliminuje ryzyko nasycenia karty sieciowej przez legalny ruch bazy danych. Jeśli obciążenie aplikacji DB2 naprawdę samo z siebie przekracza granicę gigabitów na sekundę, to gratulacje, Twoja organizacja prawdopodobnie uzyskuje wystarczającą wartość z bazy danych, aby rozważyć jej klastrowanie na wielu serwerach fizycznych (InfoSphere Warehouse lub DB2 pureScale, w zależności od obciążenia ). Jeśli od czasu do czasu napotykasz rywalizację w sieci na serwerze DB2, która jest spowodowana głównie przez inny ruch, taki jak pamięć masowa podłączona do sieci lub tworzenie kopii zapasowych w sieci, ruch ten można wyizolować do określonych kart sieciowych i z dala od klientów DB2 za pomocą technik adresowania sieciowego i trochę sprzętu do routingu/przełączania.

1
Fred Sobotka 2 marzec 2012, 00:37

Istnieje inne podejście do ograniczania połączeń z bazą danych za pomocą parametru konfiguracyjnego bazy danych CONNECT_PROC. Wystarczy utworzyć procedurę składowaną bez parametrów i dodać w tym parametrze konfiguracyjnym.

Procedura składowana zezwoli lub odmówi połączenia, pobierając informacje ze środowiska.

Więcej informacji można znaleźć w tym dokumencie: http://www .ibm.com/developerworks/data/library/techarticle/dm-1305db2access/index.html

0
AngocA 6 maj 2013, 18:41