KONCEPCJA DOCELOWEJ INFRASTRUKTURY TECHNICZNEJ

Transkrypt

Załącznik nr 1 do OPZ
KONCEPCJA DOCELOWEJ INFRASTRUKTURY
TECHNICZNEJ (WERSJA UJEDNOLICONA)
Koncepcja docelowej infrastruktury technicznej
Spis treści
1. Wprowadzenie .............................................................................................. 3
1.1. Cel dokumentu ............................................................................................ 3
1.2. Zastosowane skróty i pojęcia ........................................................................ 3
2.
Opis .............................................................................................................. 7
2.1. Stan bieżący infrastruktury ePUAP ................................................................. 7
2.2. Cele rozbudowy infrastruktury ePUAP ............................................................. 8
3.
Rozbudowa infrastruktury ............................................................................ 9
3.1. Równoważenie ruchu .................................................................................... 9
3.2. Bazy danych ............................................................................................... 9
3.3. Serwery drugiego ośrodka ........................................................................... 11
3.4. Środowisko testowe .................................................................................... 11
4.
Zestawienie sprzętu ................................................................................... 14
4.1. Zestawienie sprzętu aktualnie działającego środowiska ePUAP .......................... 14
4.2. Różnice w sprzęcie pomiędzy ośrodkami ........................................................ 16
5.
Zestawienie licencji .................................................................................... 20
5.1. Aktualne zestawienie licencji ........................................................................ 20
Strona 2 z 22
1.
WPROWADZENIE
1.1.
CEL DOKUMENTU
Dokument ma na celu przedstawienie aktualnej infrastruktury sprzętowej oraz przedstawienie
zakresu rozbudowy sprzętu i licencji infrastruktury ePUAP2 w celu zapewnienia pracy ośrodków
ePUAP w trybie Active-Active z równoważeniem obciążenia obu ośrodków
1.2.
ZASTOSOWANE SKRÓTY I POJĘCIA
Nazwa
AS
Objaśnienie
Autonomous System (system autonomiczny) - sieć lub grupa sieci pod
wspólną administracją i ze wspólną polityką trasowania.
Border Gateway Protocol (zewnętrzny protokół trasowania). Jest
protokołem wektora ścieżki umożliwiającym tworzenie niezapętlonych
ścieżek pomiędzy różnymi systemami autonomicznymi. BGP pozwala
na pełną redundancję w połączeniu z Internetem, jest również
używany do połączenia dwóch systemów autonomicznych, do wymiany
BGP
ruchu między tymi systemami. Rutery zestawiają pomiędzy sobą sesje
BGP, dzięki którym mogą wymieniać się informacjami o dostępnych
trasach (prefiksach) i wyznaczać najlepszą niezapętloną ścieżkę do
sieci docelowych. BGP używa się typowo jako protokołu routingu w
sieci posiadającej styki internetowe z 2 (lub więcej) dostawcami
Internetu.
Elektroniczna Platforma Usług Administracji Publicznej - zbiór
ePUAP
produktów projektu ePUAP-WKP i nowych rozwijanych w ramach
projektu ePUAP2.
Projekt, którego realizacja planowana jest na lata 2009-2013,
ePUAP2
stanowiący kolejny etap realizacji docelowej architektury platformy
ePUAP.
Fibre Channel - standard magistrali szeregowej definiujący
wielowarstwową architekturę, która służy do przesyłania danych przez
FC
sieć. Jest stosowany w sieciach SAN. Niezależnie od nazwy, Fibre
Channel pracuje zarówno na połączeniach galwanicznych (prawie
zawsze miedzianych) jak i światłowodach.
Znany również jako tunelowanie FC – technika transmisji danych FC
FCIP, Fibre Channel over IP,
poprzez sieć internetową (bazującą na IP). Mechanizmy FCIP
Fibre Channel over Ethernet
pozwalają na łączenie urządzeń sieci SAN znajdujących się w
oddalonych od siebie lokalizacjach.
Strona 3 z 22
Nazwa
Objaśnienie
Zapora ogniowa - jeden ze sposobów zabezpieczania sieci i systemów
przed intruzami. Może to być zarówno dedykowany sprzęt
komputerowy wraz ze specjalnym oprogramowaniem, jak i samo
oprogramowanie blokujące niepowołany dostęp do komputera. Pełni
Firewall
rolę połączenia ochrony sprzętowej i programowej sieci wewnętrznej
LAN przed dostępem z zewnątrz tzn. sieci publicznych, Internetu,
chroni też przed nieuprawnionym wypływem danych z sieci lokalnej na
zewnątrz. Do jego podstawowych zadań należy filtrowanie połączeń
wchodzących i wychodzących oraz tym samym odmawianie żądań
dostępu uznanych za niebezpieczne.
HA
High Availability (wysoka dostępność) – użyte w kontekście klastrów
HA
High availability disaster recovery (Usuwanie skutków awarii w
środowisku o wysokiej dostępności, dotyczy baz DB2) - rozwiązanie z
zakresu replikacji danych zapewniające wysoką dostępność zarówno w
wypadku częściowej, jak i całkowitej awarii lokacji. Funkcja HADR
zabezpiecza przed utratą danych, umożliwiając wykonanie replikacji
zmian ze źródłowej (podstawowej) bazy danych do docelowej
(rezerwowej) bazy danych. Całkowita awaria serwisu może wystąpić
wówczas, gdy w wyniku katastrofy, takiej jak pożar, nastąpi
zniszczenie całego ośrodka. Ponieważ w funkcji HADR do komunikacji
HADR
między podstawową a rezerwową bazą danych używany jest protokół
TCP/IP, te bazy danych mogą znajdować się w różnych miejscach.
Jeśli w wyniku katastrofy zniszczona zostanie podstawowa baza
danych, jej funkcje zostaną przejęte przez zdalną rezerwową bazę
danych i zapewniony będzie dostęp do danych oraz wszystkich funkcji
programu DB2. Po zakończeniu operacji przejęcia funkcji przez
rezerwową bazę danych możliwe będzie ponowne uruchomienie
oryginalnej podstawowej bazy danych i przywrócenie jej statusu
podstawowej bazy danych; operacja ta jest określana jako
przełączenie poawaryjne.
Interior BGP – odmiana protokołu BGP, występuje gdy sesja
iBGP
nawiązywana jest między dwoma routerami brzegowymi w obrębie
jednego AS.
Internet Protocol - protokół komunikacyjny warstwy sieciowej modelu
IP
OSI (warstwy internet w modelu TCP/IP). Używany powszechnie w
Internecie i sieciach lokalnych.
Klaster
Jest to grupa serwerów widocznych dla użytkowników jako jeden
system (jako jeden serwer lub jako jedna aplikacja).
Strona 4 z 22
Nazwa
Objaśnienie
Jest to odmiana klastra wysokiej dostępności, w której serwer
Klaster bezpieczeństwa
zapasowy odbiera dane dotyczące zmian od serwera podstawowego i
w każdej chwili jest w stanie przejąć jego zadanie. Serwer zapasowy
normalnie nie uczestniczy we wprowadzaniu nowych danych do bazy.
Klaster wysokiej dostępności – jest to grupa serwerów widocznych dla
Klaster HA
użytkowników jako jeden system (jako jeden serwer lub jako jedna
aplikacja) zapewniający wysoką dostępność do krytycznych aplikacji i
danych.
LoadBalance, load balancing
Technika rozpraszania obciążenia pomiędzy wiele procesorów,
komputerów, dysków, połączeń sieciowych lub innych zasobów.
Ośrodek A
Jest to obecny ośrodek podstawowy
Ośrodek B
Jest to obecny ośrodek zapasowy
Processor Value Unit – jednostka miary używana w licencjonowaniu
PVU
firmy IBM, służąca do zróżnicowania licencji na oprogramowanie w
zależności od klasy sprzętu na jakim ma pracować. Typową ilością PVU
na rdzeń procesora jest 100.
Urządzenie sieciowe pracujące w trzeciej warstwie modelu OSI. Służy
do łączenia różnych sieci komputerowych (różnych w sensie
informatycznym, czyli np. o różnych klasach, maskach itd.), pełni więc
Router
rolę węzła komunikacyjnego. Na podstawie informacji zawartych w
pakietach TCP/IP jest w stanie przekazać pakiety z dołączonej do
siebie sieci źródłowej do docelowej, rozróżniając ją spośród wielu
dołączonych do siebie sieci. Proces kierowania ruchem nosi nazwę
trasowania, routingu lub rutowania.
SAN
Storage area network (sieć pamięci masowej) - rodzaj sieci służący do
dostępu do zasobów pamięci masowej przez systemy komputerowe.
Juniper Networks SSG550M – wysokiej wydajności specjalizowana
SSG 550M
brama z wbudowanymi mechanizmami ochrony sieci takimi jak:
firewall, system antywirusowym, system antyspamowym. Może
pracować jako router BGP.
Inaczej Load Balancer. Serwery LoadBalance mają za zadanie
Serwer LoadBalance
rozłożyć równomiernie obciążenie np. do kilku identycznych serwerów
aplikacji. Serwery LoadBalance zapewniają, że awaria jednego z
serwerów nie jest odczuwalna przez użytkowników aplikacji.
Silnik formularzy
Składnik ePUAP, który udostępnia środowisko uruchomieniowe dla
aplikacji interaktywnych (formularzy elektronicznych).
Strona 5 z 22
Nazwa
Objaśnienie
Przełącznik - urządzenie łączące segmenty sieci komputerowej
Switch
pracujące głównie w drugiej warstwie modelu ISO/OSI (łącza danych),
jego zadaniem jest przekazywanie ramki między segmentami sieci z
doborem portu przełącznika, na który jest przekazywana.
Switch FC
Odmiana przełącznika wykorzystywana w technologii Fibre Channel.
Strona 6 z 22
2. OPIS
2.1.
STAN BIEŻĄCY INFRASTRUKTURY EPUAP
Rysunek: Schemat bieżącej infrastruktury ePUAP
Dotychczasowa infrastruktura opiera się na dwóch ośrodkach obliczeniowych, przy czym jeden
ośrodek jest ośrodkiem aktywnym (podstawowym), drugi jest pasywnym (zapasowym), co
niesie za sobą następujące problemy:

Wymiana danych między tymi ośrodkami jest wymianą jednokierunkową i polega
jedynie na powielaniu zawartości macierzy dyskowej z ośrodka podstawowego do
ośrodka zapasowego. Mirroring macierzy odbywa się z wykorzystaniem tunelu VPN
pomiędzy ośrodkami i technologii Fibre Channel over Ethernet.

Cała komunikacja z Internetu jest kierowana poprzez łącze jednego dostawcy do
ośrodka podstawowego.

W przypadku awarii ośrodka podstawowego administratorzy muszą ręcznie rozłączyć
mirroring danych między ośrodkami i włączyć serwery ośrodka zapasowego.

W przypadku awarii ośrodka podstawowego administratorzy muszą przełączyć cały ruch
do ośrodka zapasowego poprzez łącza drugiego dostawcy.
Posiadane licencje pozwalają na pracę jednego ośrodka i powielanie danych na poziomie
macierzy do ośrodka zapasowego.
W każdym ośrodku znajduje się środowisko testowe, przy czym pod względem funkcjonalnym i
mocy obliczeniowej ich parametry są zmniejszone względem środowiska produkcyjnego.
Ośrodek zapasowy ma mniejszą moc obliczeniową względem ośrodka podstawowego.
Strona 7 z 22
2.2.
CELE ROZBUDOWY INFRASTRUKTURY EPUAP
Rozbudowa infrastruktury ma zrealizować następujące cele:
1. zapewnienie pracy ośrodków ePUAP (podstawowego i zapasowego w trybie Active-Active) z
równoważeniem obciążenia obu ośrodków, z uprzednim wyspecyfikowaniem koniecznego do
zakupu oprogramowania, licencji, sprzętu teleinformatycznego niezbędnego do działania
ośrodków w trybie Active-Active,
2. zwiększenie mocy obliczeniowej i zdolności gromadzenia danych Systemu ePUAP,
3. budowa środowiska pre-produkcyjnego odpowiadającego środowisku produkcyjnemu po
rozbudowie, znajdującego się w jednym z ośrodków przetwarzania danych.
Rysunek: Schemat ośrodków po rozbudowie
Zapewnienie powyższych celów odnośnie środowiska produkcyjnego możliwe jest po spełnieniu
następujących warunków:

równoważenie ruchu wymaga użycia dodatkowych serwerów LoadBalance na wejściu
ośrodków,

oba ośrodki muszą pracować na tych samych danych (replikacja danych i aplikacji) –
odpowiadające sobie aplikacje z obydwu ośrodków muszą pracować na jednej bazie
danych,

oba ośrodki muszą mieć porównywalną moc i funkcjonalność – przy równoważeniu
ruchu przy pomocy serwerów LoadBalance ośrodki obciążane są z reguły równomiernie.
Strona 8 z 22
3. ROZBUDOWA INFRASTRUKTURY
3.1.
RÓWNOWAŻENIE RUCHU
W przypadku ośrodków pracujących w trybie Active-Active proponowany jest podziału ruchu z
wykorzystaniem obecnej infrastruktury.
W przypadku obu ośrodków przetwarzania danych Systemu ePUAP, dwa serwery LoadBalance
tworzą klaster HA poprzez wykorzystanie dodatkowych switch-y, umożliwiając redundancję tras
połączeń.
Rozwiązanie to umożliwia:
1. Szybkie równoważenie ruchu na dwa ośrodki.
2. Nie wymaga dużego nakładu pracy przy dostosowaniu obu ośrodków do pracy w trybie
Active-Active.
3.2.
BAZY DANYCH
Przy pracy ośrodków w trybie Active-Active wymagane jest, by serwery aplikacyjne obydwu
ośrodków pracowały na spójnej bazie danych. W związku z tym możliwy jest warianty zmiany
pracy z bazą danych poprzez zmianę mirroringu na klaster baz.
Dane
wszystkich
serwerów
aplikacyjnych
zlokalizowane
są
na
mirrorowanej
macierzy.
Analogiczne serwery z obu ośrodków posiadają identyczną konfigurację. Koncepcja zakłada
całkowitą lub częściową rezygnację z mirroringu. Ponieważ nie jest możliwa praca dwóch
serwerów na tym samym adresie IP zmianie muszą ulec przynajmniej adresy IP serwerów
ośrodka zapasowego. Dodatkowo należy tak skonfigurować routery ośrodków, by serwery
aplikacyjne jednego ośrodka mogły uzyskać połączenie z serwerem bazy danych drugiego
ośrodka.
3.2.1.
Zmiana mirroringu na klaster baz
Klastry baz danych realizuje się w oparciu o przynajmniej dwa serwery baz danych. Serwery te
pracują na wspólnych danych. W przypadku dużych odległości między serwerami stosuje się
klaster bezpieczeństwa, w którym jeden serwer pełni rolę serwera podstawowego a drugi jest
serwerem zapasowym. Serwer podstawowy wysyła do serwera zapasowego wszelkie informacje
o zmianach w bazie danych. Każdy z serwerów musi pracować na swoich niezależnych
zasobach, stąd konieczne jest zrezygnowanie z mirroringu danych serwera bazy.
W przypadku rozbudowy systemu, konieczne jest:
1. Wyłączenie mirroringu macierzy pomiędzy ośrodkami przetwarzania danych.
2. Zmiana konfiguracji serwerów aplikacyjnych, w celu zapewnienia ich połączenia z
klastrem serwerów baz danych.
Z powyższego rozwiązania wynikają następujące zalety:
Strona 9 z 22
1. Po
wyłączeniu
mirroringu
możliwe
jest
przekonfigurowanie
serwerów
ośrodka
zapasowego korzystających z macierzy bez konieczności przenoszenia ich danych w inne
miejsce.
2. W przypadku uszkodzenia jednego z serwerów baz, nie jest konieczne ręczne
przełączenie na drugi serwer, przełączenie następuje automatycznie, bez utraty danych.
(Klaster zapewnia spójność danych na serwerach.) Wszystkie serwery aplikacyjne
automatycznie zaczynają korzystać z drugiego serwera. Po przywróceniu do pracy
uszkodzonego serwera, klaster automatycznie wyrównuje stan baz i wraca do
pierwotnej konfiguracji (serwer podstawowy i zapasowy).
3. Zamiana mirroringu macierzy na klaster baz danych, nie wymaga zmian sprzętu.
Rysunek: Baza danych - klaster
3.2.2.
Preferowana koncepcja rozbudowy
Rekomenduje się rozwiązanie zawierające klaster baz danych, z czego płyną następujące
korzyści:
1. Zabezpieczenie danych serwerów baz jest równie dobre jak mirroring (dodatkowo w
razie awarii jednego serwera klaster pracuje dalej).
2. Ponowne aktywowanie uszkodzonego serwera nie spowoduje przerwania pracy klastra.
Rekomendowana koncepcja niesie za sobą następujące działania:
Strona 10 z 22
1. Obecna infrastruktura ogranicza możliwość budowania klastra baz danych do klastra
bezpieczeństwa HADR, w którym to podstawowy serwer bazy jest umieszczony w
ośrodku A, a zapasowy serwer w ośrodku B.
2. Zmiana na klaster baz wymusza zmianę licencji na oprogramowanie baz danych.
3. Aktualnie zainstalowana baza DB2 w wersji 9.1 nie ma możliwości stworzenia klastra
baz danych. Konieczne jest wykupienie aktualizacji do bazy w najnowszej wersji i zakup
odpowiedniej ilości licencji na serwery zapasowe lub zastąpienie proponowanego
rozwiązania rozwiązaniem równoważnym.
4. W przypadku zastosowania mechanizmu HADR, który na bieżąco replikuje bazę danych
na dodatkowym serwerze, dla każdego serwera zapasowego należy zwiększyć ilość
licencji o co najmniej 100 jednostek PVU.
3.3.
SERWERY DRUGIEGO OŚRODKA
Aktualny ośrodek zapasowy posiada mniejszą ilość serwerów biorących udział w bezpośrednim
przetwarzaniu danych oraz mniejszą ilość serwerów rezerwowych niż ośrodek podstawowy.
Oznacza to, że:
1. Oba ośrodki nie mają porównywalnej mocy obliczeniowej
2. Drugi ośrodek przetwarzania jest bardziej podatny na awarię.
Wskazane jest doposażenie drugiego ośrodka w brakujące serwery zarówno aktywne jak
i redundantne.
Rekomenduje się, że dla wszystkich serwerów, które należy aktywować w drugim ośrodku
(z wykluczeniem serwerów bazy danych) niezbędne jest dostarczenie odpowiedniej liczby
licencji na zainstalowane oprogramowanie. Zakup taki nie jest potrzebny w przypadku serwerów
redundantnych.
3.4.
ŚRODOWISKO TESTOWE
Środowisko testowe pre-produkcyjne odpowiadające strukturą środowisku produkcyjnemu
można stworzyć przenosząc serwery testowe z jednego ośrodka do drugiego. Wymagane jest
dostarczenie co najmniej trzech obudów typu blade.
Do
uzyskania
właściwej
infrastruktury
testowej
wymagane
jest
doposażenie
w
kilka
dodatkowych elementów. W ośrodku podstawowym rolę testowych serwerów baz danych pełnią
wydzielone serwery blade. Stąd konieczne jest:
1. Dostarczenie serwerów baz danych w analogicznej konfiguracji jak w ośrodku
podstawowym.
2. Do uzupełnienia infrastruktury pre-produkcyjnej wymagany jest zakup dodatkowych
obudów serwerów blade i kart blade'owych.
Strona 11 z 22
3. Ponieważ środowisko pre-produkcyjne ma odpowiadać infrastrukturze jednego ośrodka
nie jest konieczne dodawanie żadnych routerów, ani serwerów LoadBalance, wystarczy
podłączenie do firewalla poprzez osobny switch.
4. Dodatkowo należy przewidzieć całkowite odseparowanie danych serwerów testowych od
danych produkcyjnych, czyli należy rozważyć zakup macierzy dyskowej dla środowiska
testowego. Zapobiegnie to zmniejszeniu wydajności środowiska produkcyjnego podczas
np. testów wydajnościowych, gdy serwery baz danych są mocno obciążone.
Rysunek: Środowisko testowe pre-produkcyjne
Środowiska pre-produkcyjnego nie można uznać za deweloperskie środowisko testowe, stąd
wymagane będą standardowe licencje na oprogramowanie, dla każdego zainstalowanego
serwera.
3.4.1.
Środowisko testowe deweloperskie
Osobno należy zorganizować środowisko testowe dla deweloperów. Ponieważ środowisko to jest
maksymalnie uproszczone można wykorzystać wirtualizację środowisk. Do tego celu należy
zakupić zestaw np. czterech wydajnych komputerów (hostów,
z kilkoma procesorami
wielordzeniowymi i dużą ilością pamięci RAM) oraz licencję na serwer maszyn wirtualnych, który
spełni następujące wymagania:
1. możliwość tworzenia kopii maszyn wirtualnych,
Strona 12 z 22
2. możliwość przenoszenia w trakcie działania maszyn wirtualnych z jednego hosta na
inny,
3. możliwość automatycznego przeniesienia maszyn z uszkodzonego hosta na pozostałe
hosty,
4. możliwość
skalowania
maszyn
wirtualnych,
tj.
zwiększenia
przydzielonej
ilości
procesorów i pamięci
5. możliwość skalowania hostów, tj. dodawania nowych hostów i zmianę ich parametrów.
Serwer maszyn wirtualnych może wykorzystywać do pracy macierz dyskową środowiska preprodukcyjnego.
W większości przypadków przy budowie deweloperskiego środowiska testowego nie są
wymagane
licencje
środowiska
produkcyjnego.
Należy
zamówić
dedykowane
licencje
deweloperskie. Niektóre edycje deweloperskie zawierają wszystkie funkcjonalności dostępne
w edycjach Enterprise i są licencjonowane na dewelopera.
Dodatkowo do stworzenia testowego środowiska deweloperskiego wymagane będzie dokupienie
licencji na serwer maszyn wirtualnych na odpowiednią ilość procesorów i pamięci.
Strona 13 z 22
4. ZESTAWIENIE SPRZĘTU
4.1.
ZESTAWIENIE SPRZĘTU AKTUALNIE DZIAŁAJĄCEGO ŚRODOWISKA EPUAP
Lp.
1.
Sprzęt
Opis
Ilość
Ośrodek A
Ośrodek B
3
3
4
4
Macierz dyskowa
1
1
IBM System Storage DS4000
Rozszerzenie dla macierzy
2
2
EXP810
dyskowej
Biblioteka taśmowa
1
1
Zewnętrzny switch FC do
2
2
NetBAY
S2
42U
Standard
Szafa
Rack Cabinet
2.
IBM BladeCenter H Chassis
Obudowa
serwerów
na
max
typu
14
blade
(HS21 XM)
3.
IBM DS4700 Express Model
72
4.
Storage
Expansion
Unit
umożliwiające
podłączenie
kolejnych
dysków
5.
IBM System Storage TS3200
Tape Library
6.
IBM TotalStorage SAN16B-2
budowy sieci SAN
7.
Juniper ISG1000 Advanced
Firewall z modułem IPS
2
2
8.
Juniper SSG 550M
Firewall z modułem AV
2
2
9.
Juniper DX-3280-SLB-SSL-S-
Terminator SSL
2
2
5
5
2C
10. CISCO WS-C3750G-24T-S
Zewnętrzny
switch
do
budowy sieci LAN
11. nCipher TMC 200
Serwer dokładnego czasu
1
1
12. nCipher DSE 200
Serwer
2
2
2
2
znakowania
czasem
13. IBM
POWER6,
4x2-core
Serwer bazy danych
4,7GHz
4.1.1.
IBM BladeCenter HS21 XM
Strona 14 z 22
Lp.
1.
Sprzęt
Ilość
Ośrodek A
Ośrodek B
37
21
37
21
20
19
80w
1
1
80W
1
1
80w
16
23
80W
16
23
2GB (2 x 1GB) PC2-5300 CL5 ECC DDR2 Chipkill FBDIMM
12
16
13
19
52
30
HS21 Xeon Dual Core 5160 3.0 GHz/1333 MHz, 4MB L2,
2x512MB MB, O/Bay SAS
2.
QLogic 4Gb SFF Fibre Channel Expansion Card for IBM
eServer BladeCenter
3.
Intel Dual Core Processor Model 5160 3.0GHz 1333MHz
4MB L2 Cache
4.
HS21,
Xeon
Quad
Core
E5450
3.00GHz/1333MHz/12MB L2, 2x1GB Chk, O/Bay SAS
5.
Intel
Xeon
QC
Processor
Model
E5450
3.0GHz/1333MHz/12MB L2
6.
HS21,
Xeon
Dual
Core
X5260
3.33GHz/1333MHz/6MB L2, 2x1GB Chk, O/Bay SAS
7.
Intel
Xeon
DC
Processor
Model
X5260
3.33GHz/1333MHz/6MB L2
8.
667MHz
9.
4GB (2 x 2GB) PC2-5300 CL5 ECC DDR2 Chipkill FBDIMM
667MHz
10.
8 GB (2x4GB kit) Quad Rank PC2-5300 CL5 ECC Low
Power
4.1.2.
IBM x3550
Zewnętrzne serwery – obsługa HSM i urządzeń sieciowych
Lp.
1.
Sprzęt
x3550,
Xeon
Quad
Core
Ilość
E5405
80W
Ośrodek A
Ośrodek B
5
5
2.0GHz/1333MHz/12MB L2, 2x1GB ChK, O/Bay 2.5in HS
SAS, SR 8k-I, PCI2.
x3550 redundant power supply 670W
4
4
3.
ServeRAID-8k Adapter
4
4
Strona 15 z 22
4.
IBM 146GB 2.5in 10K HS SAS HDD
8
8
5.
x3550,
L2,
3
3
2GB (2x1GB) PC2-5300 CL5 ECC DDR2 Chipkill FBDIMM
2
2
Xeon
5160
3.0GHz/1333MHz/2x2MB
2x512MB, O/Bay SAS, SR 8k-l, 670W p/s, Rack
6.
Memory Kit
7.
IBM 73.4GB 2.5in 10K HS SAS HDD
6
6
8.
Intel PRO/1000 PT Dual Port Server Adapter
3
3
9.
x3550 redundant power supply 670W
3
3
10.
ServeRAID-8k Adapter
3
3
11.
IBM PCI-X Riser Card for 1U Systems
3
3
12.
nShield F3, 500 TPS - SEE Ready
3
3
4.1.3.
LoadBalance
Lp.
Sprzęt
1.
FortiNet
FortiGate
Opis
Ilość
Serwer LoadBalance
Ośrodek A
Ośrodek B
2
2
4
4
621B
2.
CISCO
WS-C3750G-
24T-S lub podobny
Switche
rozdzielające
serwery
LoadBalance od reszty urządzeń
sieci
Urządzenia zastosowane obecnie w infrastrukturze mogą zostać wykorzystane do równoważenia
ruchu dla obydwu ośrodków
Zarówno switche jak i load balancery powinny być skonfigurowane do pracy w klastrach HA (w
parach).
4.2.
RÓŻNICE W SPRZĘCIE POMIĘDZY OŚRODKAMI
4.2.1.
Zestawienie serwerów w ośrodku podstawowym, nie mający odpowiedników w
ośrodku zapasowym
Poniższa tabela zawiera listę serwerów z ośrodka podstawowego, które nie mają swoich
odpowiedników w ośrodku zapasowym.
Lp.
Sprzęt
Opis
Ilość
Strona 16 z 22
1.
HS21 serwer 2 CPU + 16GB RAM
Serwer LoadBalance draco_lb2
1
2.
Serwer LoadBalance draco2_lb2
1
3.
Serwer Loadbalance lb2wew
1
4.
Serwery dla silnika formularzy
2
5.
Serwer LoadBalance wew2
1
6.
Serwer
DB2
testowy
zapasowy
1
testowy
zapasowy
1
db1/epuapdb
7.
Serwer
DB2
db2/portaldb
4.2.2.
Środowisko testowe pre-produkcyjne
Poniżej lista dodatkowego sprzętu niezbędna do uzyskania funkcjonalności odpowiadającej
ośrodkowi podstawowemu.
Lp.
Sprzęt
Opis
Ilość
Ośrodek A
1.
Szafa rack o wysokości 42U z
Szafa rack o wysokości 42U z konsolą
2
Obudowa na max 14 serwerów typu
1
konsolą
2.
Obudowa typu blade
blade
3.
Macierz dyskowa
4.
Moduły
rozszerzające
istniejących
dla
macierzy
dyskowych w celu zgodności z
macierzą
dostarczoną
Macierz dyskowa
1
Rozszerzenie dla macierzy dyskowej
2
umożliwiające
podłączenie
kolejnych
dysków
w
ramach pkt. 3 powyżej
5.
Przełącznik sieciowy
Zewnętrzny switch do budowy sieci
1
LAN
6.
Serwer typu A
Serwer bazy danych
2
7.
Serwer blade typu A - serwer
Serwer redundantny z app1 i app2
1
dwuprocesorowy, 16GB
8.
Serwer
redundantny
app2wew
z
app1wew
i
1
Strona 17 z 22
9.
Serwer blade typu C - serwer
Baza danych db2 dla ITM
1
dwuprocesorowy, 3GB
10.
11.
12.
13.
Serwer
wspierający
grupy
1
dwuprocesorowy, 3GB
blade'ów
LoadBalancer dla usług bezpieczeństwa
1
– ws, zts
LoadBalancer dla usług bezpieczeństwa
– ws, zts
Serwer blade typu D - serwer
LoadBalancery
jednoprocesorowy, 3GB
wewnętrzny ruch sieciowy na potrzeby
serwerów
działanie
rozdzielające
aplikacji
1
1
(app1wew
app2wew)
14.
Serwer blade typu D - serwer
Serwer redundantny z lb1wew
1
Serwer monitoringu zdarzeń sieciowych
1
Serwer redundantny z portal1 i portal2
1
Serwer obsługi zgłoszeń, elearningu,
1
mediawiki
Silnik formularzy 2
1
Silnik silnika formularzy 3
1
1
1
jednoprocesorowy, 3GB
15.
dwuprocesorowy, 3GB
16.
17.
18.
19.
20.
21.
22.
23.
Load
balancer
formularzy
Serwer blade typu B - serwer
Serwer
dwuprocesorowy, 5GB
sprzętowej,
dla:
monitoringu
baz
Silnik
silnika
1
infrastruktury
1
danych
i
serwera
aplikacji
24.
Serwer wsparcia monitoringu
1
Strona 18 z 22
25.
Serwer backupu serwerów
1
Serwer przeznaczony do kooperacji z
1
dwuprocesorowy, 3GB
serwerem
dwuprocesorowy, 3GB
26.
zarządzania
środowiskiem
(director)
Macierz dyskowa musi mieć pojemność analogiczną jak w środowisku produkcyjnym.
Poniżej proponowana lista sprzętu do budowy testowego środowiska developerskiego.
Lp.
Sprzęt
Opis
Ilość
Ośrodek A
1.
Szafa rack o wysokości 42U z konsolą
Szafa
rack
o
wysokości
2
42U z konsolą
2.
Przełącznik sieciowy
Zewnętrzny
switch
do
1
Serwer do klastra maszyn
4
budowy sieci LAN
3.
Serwer typu B
wirtualnych
4.
Macierz dyskowa
Macierz dyskowa
1
5.
Rozszerzenie dla macierzy dyskowej
Rozszerzenie dla macierzy
2
dyskowej
podłączenie
umożliwiające
kolejnych
dysków
Macierz dyskowa wymieniona w powyższej liście jest opcjonalna. W momencie wymiany
macierzy użytkowanych w ośrodkach można stare macierze wykorzystać jako dodatkową
przestrzeń dyskową dla maszyn wirtualnych i środowiska pre-produkcyjnego.
Strona 19 z 22
5. ZESTAWIENIE LICENCJI
Licencje na narzędzia deweloperskie Rational pozostają bez zmian, gdyż są licencjonowane na
dewelopera a nie na PVU. W związku z tym nie są one wyszczególnione w poniższych
zestawieniach.
5.1.
Lp.
AKTUALNE ZESTAWIENIE LICENCJI
Licencja
Ilość
1.
D55TWLL Licencja ibm db2 workgroup server ed value unit lic+sw maint
12 mo
1100
2.
D593TLL Licencja db2 purexml ftr workgroup svr ed value unit lic+sw
maint 12 mo
700
3.
D562DLL Licencja ibm tivoli monitoring for databases 10 value units
lic+sw maint 12 mo
80
4.
D57UMLL Licencja tivoli comp app mgr basic websphere 10 value units
lic+sw maint 12 mo
70
5.
D572ZLL Licencja websphere process server multiplatform value unit
lic+sw maint 12 mo
800
6.
D570BLL Licencja tivoli composite app manager f/soa value unit lic+sw
maint 12 mo
1200
7.
D56PNLL Licencja ibm tivoli omegamon xe for messaging value unit
lic+sw maint 12 mo
100
8.
D56P3LL Licencja websphere message broker value unit lic+sw maint 12
mo
300
9.
D56KQLL Licencja ibm websphere business monitor value unit lic+sw
maint 12 mo
300
10.
D56FULL Licencja ibm tivoli storage manager 10 value units lic+sw maint
12 mo
854
11.
D56FPLL Licencja ibm tivoli stor mgr for stor area nw 10 value units
lic+sw maint 12 mo
662
12.
D55W8LL Licencja websphere app svr value unit lic+sw maint 12 mo
2000
13.
D55UCLL Licencja websphere portal enable value unit lic+sw maint 12 mo 1000
14.
D5571LL Licencja websphere integration developer authorized user
lic+sw maint 12 mo
1
15.
D044QLL - IBM Tivoli Composite Application Manager For Applications 3
Agent Pack Processor Value Unit (PVU) License + SW Subscription &
Support 12 Months
1920
Strona 20 z 22
16.
D5826LL IBM Tivoli Monitoring Universal Agent 10 VU License + SW
Maintenance 12 Month
180
17.
D561YLL - IBM Tivoli Monitoring 10 Processor Value Units (PVUs) License
+ SW Subscription & Support 12 Months
674
18.
D570XLL IBM ITCAM for Websphere License + SW Subscription & Support
800
12 Months
19.
Red Hat Enterprise Linux5 Basic, licencja na wsparcie w okresie 3 lat
106
20.
COMARCH Security Access Manager (DRACO)
8
21.
COMARCH Sopel
8
22.
ibm tivoli netview 10 value units lic + sw s&s 12 mo, licencja
160
23.
tiv nc/omnibus tier 3 3rd pty a resource val unit lic + sw s&s 12 mo,
licencja
1
24.
tivoli nc/omnibus gateway tier 1 3rdpty connection lic + sw s&s 12 mo,
licencja
1
25.
tivoli nc/omnibus gateway tier 1 per connection lic + sw s&s 12 mo,
licencja
1
26.
tivoli netcool/omnibus base per install lic + sw s&s 12 mo, licencja
1
27.
tivoli netcool/omnibus tier 1 resource value unit lic + sw s&s 12 mo,
licencja
1
28.
tivoli netcool/webtop concurrent user lic + sw s&s 12 mo, licencja
3
29.
tivoli netcool/webtop per install lic + sw s&s 12 mo, licencja
1
30.
Reader Extension Svr 8.0 ALP Aoo License IE TIER 1
400
31.
CISCO netManager IP1.1. for 50 devices and 50 aps
4
32.
Juniper NetScreen Security Manager 11
4
33.
Apache License
-
34.
Juniper SSG550 Kaspersky-AV
4
35.
Forms
1
Strona 21 z 22
36.
Adobe Designer 8.1. WIN AOO
40
37.
Juniper ISG1000 IDP 3 lata
4
38.
Microsoft OEM Windows Server 2003
4
39.
Forms 10.0 ALP AOO
6
40.
Oracle Directory Server Enterprise
1
41.
J-Care Core Plus Support
4
42.
Zapory Juniper SSG550m
4
Strona 22 z 22

KONCEPCJA DOCELOWEJ INFRASTRUKTURY TECHNICZNEJ

Transkrypt

Podobne dokumenty

Serwer poczty przychodzącej i wychodzącej: poczta.uw.edu.pl POP3

Projektowanie i wdrażanie serwerów na platformie Linux.

Grupa Kotrak – Administrator sieci

Poczta elektroniczna, dokumenty - dostęp zdalny

Serwer Jagular

Powołujemy Was na nabór w Studenckim Radiu śAK Politechniki

QNAP-TS-409 - Meditronik.com.pl

8mega.pl | Strona poświęcona tematyce komputerowej. - Google-Buzz

Obudowa 4U, 24x3,5” typu hot swap Procesor Sześciordzeniowy, 64