WebSphere MQ - Konfiguracja : Najlepsze praktyki

Autor: Marcin Kasiński
03.07.2012 21:33:49 +0200

Standardowa konfiguracja WebSphere MQ może swobodnie być używana w środowiskach developerskich. Zdecydowanie jednak nie nadaje się ona dla środowiska produkcyjnego. Poniższe rady pozwalają odpowiednio przygotowaś środowisko aby ustrzec się problemów podczas codziennego użytkowania środowiska.

Instalacja aktualnych poprawek

Wydaje się to oczywiste, ale jako że bardzo częśto spotykałęm się z instalacją w której nie było zainstalowanych aktualnych wersji popraweklub co gorsza zainstalowana była wersja dawno nie wspierana przez IB pozwoliłem sobei na umieszczenie tej rekomendacji. Zdeczdowanie należy pamiętać o instalacjinajnowszych wersji rozwiązania oraz najświeższych poprawek. Dodatkowymzaleceniem jest instalacja nowszych wersji rozwiązania dopiero kiedy pojawi się pierwsza poprawka. Pozwoli to na przeczekanie aż inni sprawdzą, czy w nowym rozwiązaniu nie pojawiły się poważne błędy.

Rozdzielenie danych i logów na różne dyski

Wskazane jest w ramach instalacji WebSphere MQ rozdzielenie danych i logów na rożne dyski fizyczne celem separacji powyższych zasobów.

Zmiana typu logów Menadżera kolejek

Zaleca się w środowiskach produkcyjnych aby menadżery MQ utworzone były z konfiguracją określającą typ logów jako liniowe, a nie cykliczne. Logi cykliczne stosuje się w środowiskach developerskich. W środowiskach produkcyjnych zdecydowanie powinno się stosować logi liniowe. Pozwalają one w przypadku awarii systemu na odtworzenie środowiska.

Wyłączenie opóźnienia TCP

W systemach linux / unix często obserwuje się opóźnienia w operacjach TCP. Zaleca się przy zaobserwowaniu problemó wydjnościowych przy komunikacji TCP wyłączenie opóźnienia. W celu wyłączenia opóźnienia TCP na serwerze z zainstalowanym WebSphere MQ należy wykonać komendę no -o tcp_nodelayack=1 . Wyłączenie opóźnienia TCP w taki sposób aby nie było potrzeby za każdym razem po starcie serwera wykonywać polecenie „no” dokonuje się za pomocą komendy no -p -o tcp_nodelayack=1 .

Ustawienie konwersacji dla kodowania znaków

W standardowej konfiguracji konwersja znaków MQ jest wyłączona. Zdecydowanie zaleca się włączenie konwersji kodowania znaków. W przeciwnym razie nie będą mogły działać aplikacje pracujące w innej stronie kodowej niż menadżer kolejek, jak również menadżer kolejek nie będzie mógł komunikować się z innym menadżerem kolejek pracującym w innej stronie kodowej.

Nazewnictwo obiektów MQ

Rekomendowanym sposobem nazewnictwa obiektów MQ jest używanie tylko i wyłączeni dużych liter oraz cyfr. W przypadku kolejek wskazywane jest aby w nazwach była zawarta informacja o sposobie wykorzystania kolejki, np.:

MAIL.IN – kolejka z której adapter czyta komunikaty (IN)

MAIL.OUT – kolejka do której adapter zapisuje komunikaty (OUT)

MAIL.ERR – kolejka do której adapter zapisuje komunikaty przeczytane z kolejki wejściowej z którymi to komunikatami miał problem z przeprocesowaniem (ERR)

Maksymalna wielkość komunikatu

Standardową maksymalną wielkość komunikatu jest 4MB. Należy yawsye dokonać analizy czy wartość ta jest optymalna dla konkretnych kolejek i czy nie należy ją zmodyfikować.

Maksymalna głębokość kolejki

Standardowo maksymalna głębokość kolejki ustawiona jest na 5000 komunikatów. Należy dokonać analizy czy wartość ta aby na pewno jest optymalna dla konkretnych kolejek i czy nie należy ją zmodyfikować.

Security exity

W ramach zwiększenia bezpieczeństwa powinno się zastosować w konfiguracji rozwiązania security exit pozwalających np. na ograniczenie dostępu do menadżera z określonych IP.

SSL

W ramach zwiększenia bezpieczeństwa powinno się rozważyć zastosowanie SSL celem weryfikacji adapter próbującego połączyć się z menadżerem kolejek. Dodatkowo można rozważyć zastosowanie komunikacji szyfrowanej pomiędzy adapterem a menadżerem kolejek.

Uprawnienia do obiektów MQ

W ramach zwiększenia bezpieczeństwa powinno się zastosować w konfiguracji włączenie bezpieczeństwa na poziomie dostępu do obiektów MQ.

Zabezpieczenie kanałów komunikacyjnych

W ramach zwiększenia bezpieczeństwa powinno się zastosować w konfiguracji włączenie bezpieczeństwa na poziomie kanałów w taki sposób aby adaptery łączące się za pomocą konkretnego kanału wykonywały operacje na obiektach MQ w ramach konkretnego konta. Jeśli już zostanie ta rekomendacja wdrożona zaleca się przemyślanie tych uprawnień, aby nie było tak, jak niestety często się zdarza, że adapter łączący się kanałem wykonuje wszelkie operacje w ramach użytkownika mqm, czyli konta administracyjnego WebSphere MQ.

Zabezpieczenie systemowych obiektów MQ

W ramach zwiększenia bezpieczeństwa powinno się odpowiednio zabezpieczyć obiekty systemowe aby nie mogły one zostać wykorzystane do komunikacji przez adaptery.

 powrót

Zachęcam do przedstawienia swoich uwag i opinii w polu komentarzy.

Komentarze

Dodaj Komentarz

Temat:

Treść

Podpis / Twój adres email: