Transcript of SPECYFIKACJA · Web viewObsługa sprzętowego eksportu statystyk ruchu (eksport danych do kolektora...
SPECYFIKACJA................................................................
..................................................................................................................................................
„Zaprojektowanie, budow, dostaw, wdroenie, utrzymanie, serwisowanie
systemów i aplikacji tworzcych architektur platform
technologicznych oraz infrastruktury sprztowej IT dla centrum
danych SPNT Sp. z o.o. w ramach projektów: 1. "Przetwarzanie w
chmurze dla rozwoju miast cyfrowych - faza rozwoju” - Dziaanie 5.1
Programu Operacyjnego Innowacyjna Gospodarka 2. „Budowa i
wyposaenie I Etapu Pomerania Technopark w Szczecinie przy ul.
Niemierzyskiej - Poddziaanie 1.2.1 Regionalnego Programu
Operacyjnego Województwa Zachodniopomorskiego” Cz I przedmiotu
zamówienia, przedstawiamy informacje o produkcie:
1. Routery brzegowe – 2szt.
Architektura modularna, pozwalajca na instalacj moduów w postaci: -
kart liniowych, - sprztowych redundantnych moduów zarzdzajcych, -
moduów medium transmisyjnego (transreceiverów).
Architektura wewntrzna zapewniajca odseparowanie funkcji
kontrolnych (control plane) takich jak routing, sygnalizacja,
zarzdzanie od obsugi ruchu uytkowego (data plane).
Rozbudowa urzdzenia o dodatkowe karty interfejsów powinna
odbywa si bez koniecznoci instalacji dodatkowej matrycy
przeczajcej oraz koniecznoci wymiany moduów zarzdzajcych i przy
zachowaniu wszystkich wymogów funkcjonalnych i wydajnociowych
zawartych w niniejszej specyfikacji.
Wsparcie dla HA poprzez obsug przeczania kart procesorowych w tryb
active/active.
Minimum 4 sloty na karty liniowe (nie uwzgldniajc
procesorowych).
Wymagana obsuga prdkoci portów w urzdzeniu:
10Mbps/100Mbps/1Gbps/10Gbps.
Ilo pamici operacyjnej w kartach procesorowych: minimalnie
4GB.
Urzdzenie wyposaone w nastpujc ilo portów wiatowodowych (minimum):
8x10Gbps i 20x1Gbps, porty musz mie moliwo obsugi
diagnostyki moduów optycznych dostarczonych w ramach projektu;
porty musz mie moliwo obsugi moduów wiatowodowych innych
producentów ni producent urzdzenia z zachowaniem gwarancji na
sprzt.
Urzdzenie wyposaone w min 2 zasilacze AC umoliwiajce prac urzdzenia
w penej konfiguracji (tzn. przy obsadzeniu moduami wszystkich
slotów urzdzenia).
Urzdzenie wyposaone w min 2 karty procesorowe.
Wydajno matrycy przeczajcej: minimum 75Gbps.
Wydajno przeczania pakietów: minimum 50Mpps.
Sprztowe wsparcie dla penego routingu IPv4/IPv6, co najmniej:
static, OSPF, IS-IS, BGP.
Wielko tablic w sprztowej tablicy przeczania FIB dla IPv4/IPv6:
min. 1 miliona dla IPv4 i 256 tysicy dla IPv6; podane parametry
powinny by spenione dla kadego protokou niezalenie, równie przy
jednoczesnym wykorzystaniu obu protokoów; wielko tablic RIB powinna
wynosi min 2x wielko tablic FIB dla poszczególnych protokoów.
BFD musi by obsugiwane dla IPv4/IPv6
Sprztowa realizacja przeczania przecznika.
Obsuga sieci VLAN zgodna z IEEE 802.1q dla 4094 sieci VLAN
jednoczenie; obsuga dowolnej translacji identyfikatorów VLAN,
równie w przypadku zastosowania mechanizmu Q-in-Q.
Obsuga Spanning Tree 802.1d, 802.1w, 802.1s, ramki BPDU pomidzy
sieciami VLAN musz by przenoszone take przy uyciu
MPLS/VLPS.
Obsuga sprztowego eksportu statystyk ruchu (eksport danych do
kolektora flow); dla cza o przepywnoci 1Gbps - bez próbkowania
(samplingu), dla ruchu powyej 1Gbps - moliwe wykorzystanie
próbkowania (samplingu).
Wsparcie dla: PBR, VRRP.
Obsuga standardów: L2 VPN, L3 VPN, MPLS VPN, MPLS, MPLS TE,
VPLS.
Obsuga standardów: kolejkowanie na portach: min 8 kolejki na port,
limitowanie ruchu ingress/egreess na portach/vlanach, shaping lub
policing ruchu per port.
Obsuga mechanizmów kolejkowania ruchu, jego filtrowania oraz
znakowania w oparciu o 802.1p, DSCP, ToS, MPLS EXP na wszystkich
portach oraz dla poszczególnych sieci VLAN.
Obsuga SNMP v1/v2/v3 (informacje o MIB, np. specyfikacje OID, musz
by dostpne dla zamawiajcego), cli (minimum ssh/telnet),
syslog, ntp.
Obsuga oraz integracja z sieciami SDN, przynajmniej poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Zasilanie prdem przemiennym 230V AC, wyposaone w minimum dwa
redundantne zasilacze.
Architektura modularna.
Minimum 4 GB pamici RAM.
Min. 8 slotów do obsugi kart liniowych.
Min. ilo obsugiwanych portów : 40x 1Gbps, 40x 10 Gbps, 24x 40Gbps;
architektura urzdzenia gotowa na obsug min. 2x100Gbps.
Min. ilo portów zainstalowanych: 16x 40Gbps, 24x 10Gbps, 16x
1Gbps.
Redundantna praca zasilaczy - awaria jednego moduu nie moe wpyn na
prac switcha w penej konfiguracji wymiana w trybie HotSwap - bez
koniecznoci wyczania Systemu.
Moliwo redundancji kart procesorowych - praca w trybie
active/active i active/standby.
Przepustowo matrycy przeczajcej min. 4,8 Tb/s.
Przepustowo kart liniowych min. 100 Gb/s na slot.
Sprztowa obsuga iloci tras IPv4/IPv6: min. 128 000 dla IPv4 i 64
000 dla IPv6; podane parametry powinny by spenione dla kadego
protokou niezalenie, równie przy jednoczesnym wykorzystaniu obu
protokoów.
Wszystkie porty obsugiwane z pen prdkoci cza (wire speed).
Sprztowa realizacja moduu przeczania.
Obsuga nie mniej ni 100 tysicy adresów MAC na kad kart liniow
lub nie mniej ni 1 mln. na cay przecznik.
Obsuga ramek Jumbo (min. MTU 9000 bajtów).
Obsuga sieci VLAN zgodna z IEEE 802.1q dla 4000 sieci VLAN
jednoczenie oraz Q-in-Q, moliwa dowolna translacja vlanów.
Obsuga standardu 802.3ad.
Obsuga Spanning Tree 802.1d, 802.1w, 802.1s, ramki BPDU pomidzy
sieciami VLAN musz by przenoszone take przy uyciu
MPLS/VLPS.
Sprztowa obsuga QoS ingress/egress, moliwo ograniczania pasma na
porcie (globalnie) oraz moliwo ograniczenia pasma dla ruchu
okrelonego list ACL.
Sprztowa realizacja routingu.
Obsuga mechanizmu BFD.
Wymagana moliwo stworzenia klastra VRRP.
Reguy ACL w oparciu o kryteria warstw 2-4 dla ingress i
egress.
Obsuga SNMP v1/v2/v3 (informacje o MIB, np. specyfikacje OID, musz
by dostpne dla Zamawiajcego), CLI (minimum ssh/telnet), syslog,
NTP.
Obsuga oraz integracja z sieciami SDN, integracja poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U, wielko urzdzenia 1U.
Minimum dwa wewntrzne zasilacze 230V AC, z redundancj
zasilania.
Wyposaony w nastpujc ilo portów (z obsug diagnostyki moduów):
min. 40 portów 10Gbps (z czego przynajmniej 20 musi mie obsug
moduów 1Gbps i 10Gbps zamiennie), oraz minimum 4 porty
40Gbps.
Tablica adresów MAC: min. 100000 pozycji.
Urzdzenie musi si charakteryzowa wydajnoci "wire speed" dla
funkcji przecznika, wydajno: min. 500Gbs, przepustowo: min.
500Mpps.
Moliwo wsparcia dla penego routingu IPv4/IPv6, co najmniej: static,
OSPF, IS-IS, BGP.
Wsparcie dla multicast routing: PIM-SM lub PIM-DM.
Obsuga VRRP.
Obsuga PBR, IPv6 tunneling, BFD.
Obsuga DHCP Snooping, Option 82, DHCP Relay, Option 82, DHCP
Snooping Trust.
Obsuga IGMP v1/v2/v3.
Obsuga DCBX, 802.1Qbb, IEEE 802.1Qaz.
Obsuga 802.3ad.
Wsparcie dla MTU 9000 bajtów.
Moliwo obsugi BFD dla RIP, OSPF, BGP, IS-IS, VRRP, MPLS.
Funkcjonalno przeczania pakietów non-STP, zgodno z protokoem IETF
TRILL lub SPB (IEEE 802.1aq).
Wielko tablic w sprztowej tablicy przeczania FIB dla IPv4/IPv6:
min. 16000 dla IPv4 i 8000 dla IPv6; podane parametry powinny by
spenione dla kadego protokou niezalenie, równie przy jednoczesnym
wykorzystaniu obu protokoów.
Moliwo ograniczania pasma na porcie (globalnie) oraz moliwo
ograniczenia pasma dla ruchu okrelonego list ACL.
Klasyfikacja QOS po ACL, 802.1p, IP, DSCP, ToS.
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp.
Obsuga oraz integracja z sieciami SDN, poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
Dedykowany port do zarzdzania RJ-45.
4. Firewall/UTM – 2szt.
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U.
Obsuga portów 1Gbps i 10Gbps, urzdzenie musi posiada minimum 2
porty 10Gbps i 16 portów 1Gbps.
Zasilanie 230V AC z moliwoci wymiany w czasie pracy urzdzenia (tzw.
hot-swap); urzdzenie musi by wyposaone w minimum dwa zasilacze
AC.
Minimum 3Mpps dla pakietów 64 bajtów.
Minimum 2mln jednoczesnych pocze/sekund.
Minimum 2Gbps dla ruchu IPS.
Sprztowe wsparcie dla penego routingu IPv4/IPv6, co najmniej:
static,OSPF, IS-IS, BGP.
Obsuga minimum 500 sesji BGP.
Obsuga mechanizmów QOS (policing, kolejkowanie, shaping), obsuga
DSCP, IP ToS, 802.1p, WRED, obsuga tworzenia osobnych kolejek dla
rónych klas ruchu.
Ochrona przed atakami DoS/DDoS realizowana sprztowo o wydajnoci
min. 5Gbps. Dopuszcza si realizacj tego wymagania poprzez wdroenie
dedykowanego (niezalenego od UTM) urzdzenia lub systemu (równie
dziaajcego w trybie redundancji).
Urzdzenie musi posiada funkcj wykrywania i blokowania ataków
intruzów (IPS, intrusion prevention) wspomagan sprztowo. System
zabezpiecze musi identyfikowa próby skanowania, penetracji i wama,
ataki typu exploit (poziomu sieci i aplikacji), ataki destrukcyjne
i destabilizujce (D)DoS oraz inne techniki stosowane w atakach na
sie. Ustalenie blokowanych ataków (intruzów, robaków) musi odbywa
si w reguach polityki bezpieczestwa. Baza sygnatur IPS musi by
utrzymywana i udostpniana przez producenta urzdzenia
firewall.
Obsuga statefull firewall dla ruchu IMIX z wydajnoci nie
mniejsz ni 10Gbps.
System zabezpiecze musi identyfikowa próby skanowania, penetracji,
wama, ataki typu exploit, ataki destrukcyjne i
destabilizujce.
Obsuga pracy w trybie HA Active-Active, tak by przeczanie pomidzy
urzdzeniami odbywao si przezroczycie dla ruchu uytkowników;
mechanizm ochrony przed awariami musi monitorowa i
wykrywa uszkodzenia elementów sprztowych i programowych
systemu zabezpiecze oraz czy sieciowych.
Wsparcie dla VPN-IPSEC.
Obsuga IPv4, IPv6.
Obsuga SNMP v1/v2/v3 (informacje o MIB, np. specyfikacje OID, musz
by dostpne dla zamawiajcego), CLI (minimum ssh/telnet), syslog,
NTP.
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
5. Load balancers – 2szt.
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
Musi by urzdzeniem sieciowym, przystosowanym do montau w szafie
RACK 19U lub oprogramowaniem dedykowanym do wirtualizacji i
przystosowanym do uruchomienia w ramach infrastruktury IaaS.
W przypadku urzdzenia dedykowanego: powinno by wyposaone w
porty minimum 2x 10Gbps oraz minimum 2x 1Gbps.
Minimalnie 8GB RAM.
Minimum 250GB pojemnoci dysku twardego.
Wsparcie load balancing dla: TCP, UDP, HTTP, HTTPS.
Minimum 2Gbps dla ruchu L4/L7.
Minimum 4 miliony jednoczesnych pocze L4.
Zapewnienie dowolnej liczby sesji load balance na poziomie TCP,
UDP, HTTP, HTTPS.
Obsuga algorytmów load balance: round robin, wagowany round robin,
random losowy, najmniejsza liczba pocze, wagowany.
Obsuga zarzdzania sesj uytkownika przez adres ródowy lub HTTP
Cookie.
Obsuga zarzdzania LB wraz z opcjami automatycznego
podczenia/odczenia load balancowanych nodów powinna
by realizowana przez funkcjonalno urzdzenia, instancji
wirtualnej lub dostarczony system zarzdzania - w kadym przypadku
wymagana jest integracja z IaaS.
Obsuga terminacji SSL dla One-Way SSL i Two-Way SSL.
Obsuga certyfikatów SSL dowolnego dostawcy.
Zarzdzanie nagówkami HTTP przekazywanymi do node'ów (w tym
nagówkami z polami certyfikatów SSL).
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp.
Monitoring urzdzenia powinien by realizowany przez dedykowane
Podsystemy monitoringu Centrum Danych (np. za pomoc SNMP).
6. Serwery – 64szt.
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
Architektura serwerowa, zalecany jest dobór serwerów typu "high
density servers" z grupowaniem serwerów per obudowa ze wspólnym
zasilaniem w celu optymalizacji zuycia energii elektrycznej.
Minimum 6 dysków hot-swap z obsug SAS/NL-SAS/SATA/SSD dla
pojedynczego node serwera.
2 porty USB.
1 port VGA.
1 slot PCI-E.
Zainstalowane 2 porty 10Gbps, wspierajce sprztowo: - 802.1q VLAN -
TCP segmentation offload - IPv6 obsuga dla IP/TCP i IP/UDP receive
checksum offload - wsparcie dla wirtualizacji oraz obsuga ramek
jumbo o rozmiarze min.9000 bajtów.
Zainstalowane 2 porty 1Gbps miedziane.
Zainstalowany 1 port dedykowany na zarzdzanie.
Zainstalowane minimum 64GB RAM 1866Mhz ECC Registered, obsuga
maksimum 256GB 1866Mhz ECC Registered w jednym serwerze, sumaryczna
ilo pamici RAM w caym rodowisku nie moe by mniejsza ni:
3840GB.
Minimum 16 rdzeni procesora na serwer (nie uwzgldniajc
wielowtkowoci procesora, tzw. HT), taktowanie: min. 2.5Ghz na
rdze.
Minimum 16MB last level cache per processor.
Oferowany model procesora musi osiga w tecie CPU MARK wynik bazowy
minimum 10000pkt. (wynik zaproponowanego procesora musi znajdowa si
na stronie http://www.cpubenchmark.net/ w dniu skadania ofert.
Wydruk ze strony zaczy do oferty).
Ewentualna rozbudowa o dodatkowy procesor lub inny osprzt musi
odbywa si bez dodatkowych licencji.
Wsparcie dla procesora do wirtualizacji.
Minimum 46TB pojemnoci dysków enterprise SATA SSD (pojemno RAW,
sumarycznie na wszystkich serwerach) oraz minimum 768TB pojemnoci
dysków SATA enterprise (pojemno RAW, sumarycznie na wszystkich
serwerach); rozmieszczenie pooenia dysków w poszczególnych
obudowach powinno zosta dobrane na etapie projektu technicznego z
uwzgldnieniem wybranego podejcia do rozproszonego storage;
przykadowy podzia: 48 serwerów w obudowach po 8 sztuk kada,
wyposaonych w 2x 480GB SSD kady oraz 16 serwerów wyposaonych w 16x
3TB SATA kady. MTBF dla kadego z dysków zastosowanych w serwerach
minimum 1.4 miliona godzin dla enterprise SATA i minimum 2 miliony
godzin dla enterprise SATA SSD. Dla dysków SSD parametr TBW (Total
Bytes Written) powinien wynosi min. 270TB (w rozumieniu standardów
JESD218 oraz JESD 219).
Wyposaony w sprztowy kontroler dysków z minimum 1GB pamici,
obsugujcy dyski SAS, NL-SAS, SATA, SSD z obsug RAID przynajmniej
poziom 0, 1, 10, 5.
Obsuga dysków SAS/SATA/SSD dowolnego producenta, w tym moliwo uycia
dysków tzw. OEM (niekoniecznie dedykowanych/markowych);
wykorzystanie dysków OEM nie powinno zmniejsza programowo lub
licencyjnie wydajnoci/przepustowoci Systemu oraz nie powinno
powodowa utraty gwarancji.
Zarzdzanie urzdzeniami poprzez IPMI (Intelligent Platform
Management Interface), zgodno z IPMI 2.0, KVM over LAN / KVM over
IP.
Obsuga IPv4, IPv6.
Obsuga interfejsu WWW dla zarzdzania.
Zarzdzanie serwerem przy wyczonej maszynie, moliwe uruchomienie
zdalne systemu, restart, wyczenie, wczenie, moliwo montowania
obrazu oraz instalacji systemu operacyjnego za pomoc interfejsu
zarzdzania.
7. Macierz – 1szt.
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
Uzupenienie istniejcej infrastruktury IBM w postaci macierzy IBM
V3700 z 4 moduami rozszerze.
Moduowa do instalacji w standardowej szafie Rack 19”.
Dwa redundantne kontrolery udostpniajce w sumie nie mniej ni 8
pocze FC 8Gb i 4 poczenia iSCSI minimum 1Gb. RAID 0,1,5,6,10.
Wymagane jest, aby architektura wewntrzna macierzy wykorzystywaa
standard SAS 2.0.
Co najmniej 16GB pamici „cache”. Pami „cache” przeznaczona dla
procesu zapisu musi by zabezpieczona przed skutkami awarii jednego
z kontrolerów.
Macierz musi obsugiwa dyski SSD (o pojemnociach 200GB i 400GB), SAS
(o pojemnociach 146GB, 300GB, 600GB, 900GB) i NL-SAS lub SATA (o
pojemnociach 500GB, 1TB, 2TB, 4TB) pozwalajc na rozbudow do co
najmniej 120 dysków. Macierz musi obsugiwa dyski 2,5” i 3,5”.
Macierz musi umoliwia mieszanie dysków SAS, NL-SAS i SSD w ramach
jednej póki dyskowej. Dostawa ma obejmowa 48 dysków SATA kady o
pojemnoci 4TB oraz 24 dysków SSD kady o pojemnoci 400GB.
Macierz musi mie moliwo wykonywania migracji woluminów w ramach
zasobów dyskowych bez zatrzymywania aplikacji z nich korzystajcych.
Macierz musi posiada moliwo migracji danych z zewntrznych zasobów
dyskowych.
Macierz musi obsugiwa min 50 kopii migawkowych na macierz. Licencja
na t funkcjonalno musi by zawarta w cenie. Kopie danych typu
„snapshot„ musz by wykonywane przez macierz jako pojedyncza
operacja w co najmniej trzech moliwych trybach: • kopia pena, •
kopia wskanikowa, • przyrostowa kopia pena. Macierz musi mie moliwo
odtworzenia zawartoci woluminu logicznego z kopii typu „snapshot”
bez koniecznoci kopiowania danych za porednictwem serwera.
Funkcjonalno konfigurowania woluminu dyskowego posiadajcego dwie
kopie fizyczne na rónych grupach dyskowych i rónego typu (np.:
jedna kopia z nadalokacj druga bez). W przypadku zapisu macierz
zapisuje do obu kopii synchronicznie. W przypadku odczytu czyta
tylko z jednej kopii. Kiedy jedna kopia jest niedostpna macierz
automatycznie korzysta tylko z dostpnej kopii a po naprawie
brakujcej kopii automatycznie synchronizuje dane. Wolumin
mirrorowany moe by przeksztacony w zwyky wolumin poprzez usunicie
jednej kopii albo poprzez wyodrbnienie jednej kopii w osobny
wolumin.
Funkcjonalno dynamicznej alokacji przestrzeni dyskowej wikszej ni
jest dostpna fizycznie oraz moliwo wyczenia tej funkcjonalnoci dla
wybranych woluminów.
Wszystkie krytyczne komponenty takie jak: kontrolery dyskowe, pami
„cache”, zasilacze i wentylatory musz by zdublowane w taki sposób,
aby awaria pojedynczego elementu nie wpywaa na funkcjonowanie caego
Systemu. Brak pojedynczego punktu awarii. Wszelkie poczenia pomidzy
elementami skadowymi macierzy (wszystkie cieki) musz by
redundantne. Wsparcie dla zasilania z dwóch niezalenych róde prdu
poprzez nadmiarowe zasilacze typu „hot-swap”. Wentylatory typu
„hot-swap”.
Interfejs zarzdzajcy GUI, CLI nie wymagajcy instalacji dodatkowego
oprogramowania na stacji zarzdzajcej. Moliwo zmiany mikrokodu bez
przerywania dostpu do danych. Monitorowanie stanu pracy za
porednictwem protokou SNMP. Automatyzacja procesu informacji o
stanie urzdzenia, w tym informacji o awariach za pomoc wiadomoci
przesyanych drog elektroniczn.
Komplet wkadek FC, okablowanie zasilajce, wiatowodowe FC
8. Rozbudowa macierzy – 1szt.
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
Dwa redundantne kontrolery udostpniajce w sumie nie mniej ni 8
pocze FC 8Gb i 2 poczenia iSCSI minimum 1Gb. RAID 0,1,5,6,10.
Wymagane jest, aby architektura wewntrzna macierzy wykorzystywaa
standard SAS 2.0. Rozbudowana macierz nie powinna posiada
programowych ogranicze wydajnoci.
Obudowa moduowa do instalacji w standardowej szafie Rack 19”.
Rozbudowana macierz musi obsugiwa dyski SSD (o pojemnociach 200GB i
400GB, 800GB), SAS (o pojemnociach 146GB, 300GB, 600GB, 900GB i 1,2
TB) i NL-SAS lub SATA (o pojemnociach 500GB, 1TB, 2TB, 4TB)
pozwalajc na rozbudow do co najmniej 120 dysków. Macierz musi
obsugiwa dyski 2,5” i 3,5”. Macierz musi umoliwia mieszanie dysków
SAS, NL-SAS i SSD w ramach jednej póki dyskowej. Dostawa macierzy
musi obejmowa minimum 9TB SSD pojemnoci RAW oraz minimum 43TB SAS
pojemnoci RAW.
Naley dostarczy komplet wkadek FC, okablowanie zasilajce,
wiatowodowe FC.
9. Switche MGMT – 6szt.
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
Switch klasy operatorskiej; min. ilo urzdze tych urzdze powinna
by zgodna z zestawieniem ilociowym; w przypadku gdy projekt
techniczny wykae wiksze zapotrzebowanie naley dostarczy ilo zgodn z
projektem technicznym.
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U, wielko urzdzenia 1U.
Minimum dwa wewntrzne zasilacze AC, z redundancj zasilania.
Wyposaony w nastpujc ilo portów: min. 48 portów 10/100/1000Mbps ,
oraz minimum 4 porty 1Gbps.
Wielko tablicy mac-adresów minimum 12000 pozycji.
Urzdzenie musi by wire speed dla funkcji przecznika, wydajno
minimum 50Gbs, przepustowo minimum 50Mpps.
Obsuga IPv4/IPv6.
Obsuga DHCP Snooping, Option 82, DHCP Relay, Option 82, Dhcp
Snooping Trust.
Obsuga 4000 jednoczesnych VLAN, translacji VLAN.
Obsuga Spanning Tree, 802.1d, 802.1w, 802.1s.
Obsuga 802.3ad.
Kontrola MAC adresów w poszczególnych VLANACH, obsuga wykrywania
ptli tzw. loop detection.
Wsparcie dla MTU 9000 bajtów.
Tablica routingu minimum 4000 wpisów dla IPv4 oraz 1000 wpisów dla
IPv6.
Moliwo ograniczania pasma na porcie (globalnie) oraz moliwo
ograniczenia pasma dla ruchu okrelonego list ACL
Klasyfikacja QOS po ACL, 802.1p, IP, DSCP, ToS;
Funkcja mirroringu portów: 1 to 1 Port mirroring, Many to 1 port
mirroring
Moliwo wyboru sposobu obsugi kolejek – Strict Priority; Weighted
Round Robin;
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp
Obsuga oraz integracja z sieciami SDN, poprzez otwarty
protokó
Obsuga RADIUS/TACACS/TACACS+
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
Dedykowany port do zarzdzania RJ-45
10. Switche MGMT – agregacja – 1szt.
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U, wielko urzdzenia 1U.
Minimum dwa wewntrzne zasilacze AC, z redundancj zasilania.
Wyposaony w nastpujc ilo portów: min. 20 portów 1Gbps.
Wielko tablicy MAC adresów minimum 12000 pozycji.
Urzdzenie musi by wire speed dla funkcji przecznika, wydajno
minimum 20Gbs, przepustowo minimum 20Mpps.
Obsuga IPv4/IPv6.
Obsuga DHCP Snooping, Option 82, DHCP Relay, Option 82, Dhcp
Snooping Trust.
Obsuga 4000 jednoczesnych VLAN, translacji VLAN.
Obsuga Spanning Tree, 802.1d, 802.1w, 802.1s.
Obsuga 802.3ad.
Kontrola MAC adresów w poszczególnych VLANACH, obsuga wykrywania
ptli tzw. loop detection.
Wsparcie dla MTU 9000 bajtów.
Tablica routingu minimum 4000 wpisów dla IPv4 oraz 1000 wpisów dla
IPv6.
Moliwo ograniczania pasma na porcie (globalnie) oraz moliwo
ograniczenia pasma dla ruchu okrelonego list ACL.
Klasyfikacja QOS po ACL, 802.1p, IP, DSCP, ToS.
Funkcja mirroringu portów: 1 to 1 Port mirroring, Many to 1 port
mirroring.
Moliwo wyboru sposobu obsugi kolejek – Strict Priority; Weighted
Round Robin.
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp.
Obsuga oraz integracja z sieciami SDN, poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
Dedykowany port do zarzdzania RJ-45.
11. Konwertery, moduy (transceivers)
Konwertery powinny poprawnie wspópracowa z portami sieciowymi do
których zostan podczone. W przypadku konwerterów optycznych naley
zalenie od wykorzystanych pocze wiatowodowych dobra odpowiedni
rodzaj (single/multi mode), moc optyczn (LX, SX, ZX) i jeeli jest
taka potrzeba wprowadzi tumiki optyczne.
Ilo i rodzaj konwerterów powinny zosta dobrane w trakcie
przygotowywania projektu technicznego w taki sposób aby:
- spenia zaoone wymogi przepywnociowe pomidzy wzami i warstwami
sieci, - gwarantowa zachowanie wymogów dostpnoci i redundancji, -
zapewni poczenia do istniejcej infrastruktury. Do iloci wynikajcej
z projektu technicznego naley doliczy 5% kadego rodzaju
konwertera.
Producent dostarczonych urzdze musi dopuszcza moliwo wykorzystania
moduów SFP/SFP+/QSFP/QSFP+/XFP pochodzcych od innych producentów,
tzn. obsug moduów typu OEM bez utraty gwarancji czy supportu dla
urzdzenia.
Dostarczone moduy optyczne musz wspiera diagnostyk DDM (Digital
Diagnostic Monitor) lub równowan , tzn. monitorowa kluczowe
parametry pracy moduu takich jak moc optyczna sygnau nadawanego,
moc optyczna sygnau odbieranego, temperatura pracy, napicie
zasilania, prd lasera i w tym zakresie funkcjonalnym musz poprawnie
wspópracowa z urzdzeniami wyposaonymi w te moduy.
12. Bramka SMS – 1szt.
Obsuga minimum dwóch kart SIM rónych operatorów dziaajcych na
terenie Polski. Brak blokady sim-lock.
Obsuga komunikatów SMS.
Moliwo zasilania 230V AC i/lub DC z funkcj podtrzymania
bateryjnego.
Obsuga IPv4/IPv6.
Obsuga logowania wysanych wiadomoci SMS.
Obsuga funkcji routera przez dostp do Internetu z sieci GSM, w celu
awaryjnego dostpu do sieci.
Moliwo integracji z systemem monitoringu poprzez API (automatyzacja
wysyania komunikatów) przez dedykowany port komunikacyjny.
Dedykowany port do zarzdzania.
13. Kompleks biurowy SPNT: switche dostpowe – 15szt.
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U, wielko urzdzenia 1U.
Minimum dwa wewntrzne zasilacze AC, z redundancj zasilania.
Wyposaony w nastpujc ilo portów: min. 48 portów 10/100/1000Mbps ,
oraz minimum 2 porty 10Gbps.
Moliwo zbudowania jednego wirtualnego przecznika z 4 przeczników
tego samego typu tzw. funkcja stackowania; przecznik wirtualny
powinien by widziany przez inne urzdzenia sieciowe jako pojedyncze
urzdzenie zarówno pod ktem mechanizmów warstwy L2 jak i warstwy L3;
do podczenia przeczników jako przecznik wirtualny, musi by
wykorzystany dedykowany port, poczenie przez dedykowany port musi
by poczeniem w ringu, aby zminimalizowa awarie w trakcie
uszkodzenia kabla/przecznika; przepustowo portu dedykowanego do
poczenia midzy poszczególnymi urzdzeniami musi by minimum
10Gbps.
Wielko tablicy MAC adresów minimum 12000 pozycji.
Urzdzenie musi by wire speed dla funkcji przecznika, wydajno
minimum 100Gbs, przepustowo minimum 100Mpps.
Obsuga IPv4/IPv6.
Obsuga DHCP Snooping, Option 82, DHCP Relay, Option 82, Dhcp
Snooping Trust.
Obsuga IGMP v1/v2/v3.
Obsuga 802.1x, 802.3ad.
Kontrola MAC adresów w poszczególnych VLANACH, obsuga wykrywania
ptli tzw. loop detection.
Wsparcie dla MTU 9000 bajtów.
Tablica routingu minimum 4000 wpisów dla IPv4 oraz 1000 wpisów dla
IPv6.
Moliwo ograniczania pasma na porcie (globalnie) oraz moliwo
ograniczenia pasma dla ruchu okrelonego list ACL.
Klasyfikacja QOS po ACL, 802.1p, IP, DSCP, ToS.
Funkcja mirroringu portów: 1 to 1 Port mirroring, Many to 1 port
mirroring.
Moliwo wyboru sposobu obsugi kolejek – Strict Priority; Weighted
Round Robin.
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp.
Obsuga oraz integracja z sieciami SDN, poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
Dedykowany port do zarzdzania RJ-45.
14. Kompleks biurowy SPNT: switche dostpowe POE – 9szt.
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U, wielko urzdzenia 1U.
Minimum dwa wewntrzne zasilacze AC, z redundancj zasilania.
Wyposaony w nastpujc ilo portów: min. 48 portów 10/100/1000Mbps,
oraz minimum 2 porty 10Gbps.
Moliwo zbudowania jednego wirtualnego przecznika z 4 przeczników
tego samego typu tzw. funkcja stackowania; przecznik wirtualny
powinien by widziany przez inne urzdzenia sieciowe jako pojedyncze
urzdzenie zarówno pod ktem mechanizmów warstwy L2 jak i warstwy L3;
do podczenia przeczników jako przecznik wirtualny, musi by
wykorzystany dedykowany port, poczenie przez dedykowany port musi
by poczeniem w ringu, aby zminimalizowa awarie w trakcie
uszkodzenia kabla/przecznika; przepustowo portu dedykowanego do
poczenia miedzy poszczególnymi urzdzeniami musi by minimum
10Gbps.
Wielko tablicy MAC adresów minimum 12000 pozycji.
Urzdzenie musi by wire speed dla funkcji przecznika, wydajno
minimum 100Gbs, przepustowo minimum 100Mpps.
Obsuga IPv4/IPv6.
Obsuga DHCP Snooping, Option 82, DHCP Relay, Option 82, Dhcp
Snooping Trust.
Obsuga IGMP v1/v2/v3.
Obsuga 802.1x, 802.3ad.
Kontrola MAC adresów w poszczególnych VLANACH, obsuga wykrywania
ptli tzw. loop detection.
Wsparcie dla MTU 9216 bajtów.
Tablica routingu minimum 4000 wpisów dla IPv4 oraz 1000 wpisów dla
IPv6.
Moliwo ograniczania pasma na porcie (globalnie) oraz moliwo
ograniczenia pasma dla ruchu okrelonego list ACL.
Klasyfikacja QOS po ACL, 802.1p, IP, DSCP, ToS.
Funkcja mirroringu portów: 1 to 1 Port mirroring, Many to 1 port
mirroring.
Moliwo wyboru sposobu obsugi kolejek – Strict Priority; Weighted
Round Robin.
Wsparcie dla 802.3af, 802.3at tzw. POE/POE+, minimalnie 14W na port
miedziany, przy zaoeniu wykorzystania wszystkich portów moc jednego
zasilacza musi wynosi minimum 700W; urzdzenie wówczas musi
by wyposaone w dwa zasilacze kady po 700W.
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp.
Obsuga oraz integracja z sieciami SDN, poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
Dedykowany port do zarzdzania RJ-45.
15. Kompleks biurowy SPNT: switche agregujce – 2szt.
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Musi by dedykowanym urzdzeniem sieciowym, przystosowanym do
montau w szafie RACK 19U, wielko urzdzenia 1U.
Minimum dwa wewntrzne zasilacze 230V AC, z redundancj
zasilania.
Wyposaony w ilo portów, z obsug diagnostyki moduów minimum 24
porty 10Gbps.
Tablica MAC adresów minimum 32000 pozycji.
Urzdzenie musi by wire speed dla funkcji przecznika, wydajno
minimum 480Gbs, przepustowo minimum 300Mpps.
Obsuga IPv4/IPv6.
Obsuga DHCP Snooping, Option 82, DHCP Relay, Option 82, Dhcp
Snooping Trust.
Obsuga IGMP v1/v2/v3.
Obsuga 802.1x, 802.3ad.
Wsparcie dla MTU 9000 bajtów.
Funkcjonalno przeczania pakietów non-STP.
Tablica routingu minimum 10000 wpisów dla IPv4 oraz 2000 wpisów dla
IPv6.
Moliwo ograniczania pasma na porcie (globalnie) oraz moliwo
ograniczenia pasma dla ruchu okrelonego list ACL.
Klasyfikacja QOS po ACL, 802.1p, IP, DSCP, ToS.
Obsuga SNMP v1/v2/v3 (informacje o MIB musz by dostpne dla
zamawiajcego), cli (minimum ssh/telnet), syslog, ntp.
Obsuga oraz integracja z sieciami SDN, poprzez otwarty
protokó.
Obsuga RADIUS/TACACS/TACACS+
Zarzdzanie przez system zarzdzania i monitorowania pochodzcy od
tego samego producenta.
Dedykowany port do zarzdzania RJ-45.
16. Kompleks biurowy SPNT: rozszerzenia licencji kontrolerów Wi-Fi
– 2szt.
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
Wymagane 2 pakiety rozszerzenia licencji do obsugi 50 szt. Access
Pointów do dwóch kontrolerów Rucus ZoneDirector 3000.
17. Kompleks biurowy SPNT: punkty dostpowe (AP) – 43szt.
Producent /
model:..……………………………………………………………………………………………………………………………...
Dodatkowe
informacje:…………………………………………………………………………………………………………………………..
Dwa tryby pracy: samodzielny (zarzadzanie punktem odbywa si poprzez
interfejs przegldarki internetowej, telnet i SSH) oraz zarzdzania
przez kontroler sieci bezprzewodowej.
W trybie zarzdzania przez kontroler sieci bezprzewodowej
komunikacja z punktem dostpowym musi by szyfrowana.
W trybie zarzdzania przez kontroler sieci bezprzewodowej punkt
dostpowy moe znajdowa si w tej samej, lub innej podsieci IP.
Moliwo pracy jako cze sieci kratowej (tj. „mesh”) - bez podczonego
kabla Ethernet, z dynamicznym przeczeniem pomidzy trybami i
automatyczna konfiguracja.
Równoczesna praca w pasmie 2,4 GHz i 5.x GHz.
Praca w trybie MIMO 3x3:3.
Wsparcie dla metody MRC (Maximal Ratio Combining).
System musi zapewnia dostp sygnau radiowego wokó punktu dostpowego,
bez martwych pól.
System musi zapewnia maksymalne wzmocnienie 9 dBi i filtrowanie
interferencji na poziomie -15dBi.
Automatyczna ochrona przed interferencjami sygnau.
Anteny wbudowane i zintegrowane z punktem dostpowym.
System antenowy musi si skada z nie mniej ni 12 elementów.
Czuo odbiornika nie mniejsza ni -101dBm.
Nie mniej ni 32 BSSID z wasna polityka dostpu i reguami QoS.
Nie mniej ni 4 kolejki QoS per stacja kliencka i wsparcie standardu
802.11e.
Obsuga nie mniej ni 500 stacji, nie mniej ni 60 klientów gosowych
jednoczenie.
802.11d, 802.1Q, 802.1X.
IEEE 802.11a: 5.15 – 5.85 GHz
IEEE 802.11b: 2.4 – 2.484 GHz
802.11n: 6.5Mbps – 216,7Mbps (20MHz)
802.11n: 13.5Mbps – 450Mbps (40MHz)
802.11b: 11, 5.5, 2, 1 Mbps
802.11g: 54, 48, 36, 24, 18, 12, 9, 6 Mbps
Zasilanie poprzez PoE lub zasilacz 12V DC
Maksymalna pobierana moc 13W.
2 porty RJ-45, auto MDX, auto-sensing 10/100/1000 Mbps, jeden z
moliwoci zasilania PoE.
Masa urzdzenia nie wiksza ni 1 kg.
Praca w temperaturze 0-50C, wilgotno do 95% (bez
kondensacji).
Homologacja do montau w zamknitych przestrzeniach UL 2043.
Monta bez koniecznoci uycia zewntrznych akcesoriów i
maskownic.
Dynamicznego generowania kluczy Pre-Shared keys.
Automatycznego wyboru najlepszego kanau pracy w oparciu o realna
przepustowo/pojemno kanaów dla 2,4 GHz lub 5 GHz wraz z moliwoci
przeniesienia klienta na optymalny kana z wykorzystaniem standardu
802.11h.
Moliwo dobierania optymalnych kanaów transmisyjnych bez koniecznoci
przerywania transmisji danych.
Optymalizacja wydajnoci sieci przy rónych prdkociach dostpowych
klientów (sterowanie czasem dostpu do punktu dostpowego na
podstawie okien czasowych, nie iloci przesanych danych).
W celach diagnostycznych moliwo przechwycenia ramek 802.11/802.3
od/do klienta przesyanych przez punkt dostpowy bez wpywu na trwajc
komunikacje.
18. Szafy serwerowe – 4szt.
Wyposaenie w wysokoszczelny szczotkowy modu podogi do wprowadzania
kabli.
czniki zewntrzne.
Uszczelki pionowe blokady strumienia powierzchni lewej i prawej
strony LCP i poziom 19".
2 moduy mocy PDU 3x32A gniazda 3x 6xC13, 3x 2xC19, funkcja w.-wy.
Pojedyncze gniazdo model CW-24VYM.
2 modu PDU - 19" z podczeniem 32A , wyjcie 4xC19 z funkcj w-wy.
Pojedyncze gniazdo.
Czujnik temperatury i wilgotnoci.
10 wieszaków kablowych przelotowych.
Funkcja automatycznego otwierania drzwi.
19. Moduy chodzce – 2szt.
Wymagany parametr/funkcjonalno:
Oferowany parametr/funkcjonalno:
LCP T3+ EC 47U 3300235, dla chodzenia szaf serwerowych DK TS8
2200x1200, o mocy chodniczej do 30 kW.
Dwa aktywne obwody chodzenia i prdowe.
Wbudowane sterowniki monitoringu i zarzdzania zdaln prac przez
Rittal CMC TC.
Funkcja „Auto-Load-Balancing“.
Funkcja „Auto-Recovery“.
Funkcja automatycznego otwierania drzwi szafy serwerowej dla
gaszenia poaru w szafie oraz dla chodzenia awaryjnego.
Kolor RAL 7035.
………………………………………………………………………………………………………………………………………………………….
………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………………………………......
………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………....…………………………………………………………………
IaaS musi by dedykowanym rozwizaniem do budowy chmur publicznych
(public clouds), prywatnych (private clouds), serwerów VPS,
serwerów dedykowanych.
IaaS musi zapewnia zarzdzanie oraz monitorowanie du (powyej 100
000) sieci maszyn wirtualnych bd serwerów dedykowanych.
W ramach wdroenia Podsystemu IaaS musz by zapewnione mechanizmy
automatycznego provisioningu, zarzdzania, monitoringu i skalowania
maszyn wirtualnych cloud osadzonych na sprzcie compute dla
wszystkich wymaganych/wspieranych systemów operacyjnych.
W ramach wdroenia Podsystemu IaaS musz by zapewnione mechanizmy
automatycznego provisioningu, zarzdzana, monitoringu i skalowania
maszyn wirtualnych VPS osadzonych na sprzcie compute dla wszystkich
wymaganych/wspieranych systemów operacyjnych.
W ramach wdroenia Podsystemu IaaS musz by zapewnione mechanizmy
automatycznego provisioningu, zarzdzana, monitoringu serwerów
dedykowanych osadzonych na sprzcie compute dla wszystkich
wymaganych/wspieranych systemów operacyjnych.
W ramach wdroenia Podsystemu IaaS musz by zapewnione mechanizmy
automatycznego provisioningu, zarzdzania, monitoringu i skalowania
rodowiska sprztowego "Storage" dla maszyn wirtualnych cloud,
VPS.
W ramach wdroenia Podsystemu IaaS musz by zapewnione mechanizmy
automatycznego provisioningu, zarzdzania, monitoringu i skalowania
rodowiska sieciowego, w tym: sieci prywatnych (np. w oparciu o
VLAN), adresacji prywatnej i publicznej IPv4 i IPv6 oraz sieci
dostpowych VPN do usug. W przypadku protokou IPv6 jeeli oferowane
rozwizanie nie obsuguje na etapie skadania oferty tej
funkcjonalnoci, musi oferowa j na etapie realizacji Projektu.
W ramach wdroenia Podsystemu IaaS musz by zapewnione mechanizmy
automatycznego provisioningu, zarzdzania, monitoringu i skalowania
rodowiska load balancerów.
W ramach wdroenia Podsystemu IaaS musi by zapewniona obsuga dwóch
regionów: 1. "Gównego" w Centrum Danych Zamawiajcego na sprzcie
dostarczonym w ramach niniejszego zamówienia (przedmiot niniejszego
postpowania) oraz 2. "Zapasowego" na zakupionym, wdroonym i
rozbudowanym w ramach niniejszego zamówienia sprzcie znajdujcym si
w innym budynku Zamawiajcego. Ogólna specyfikacja istniejcej
infrastruktury: - compute: serwery blade IBM w obudowie rack 19U,
na potrzeby rodowiska wirtualizacyjnego, - storage: macierz IBM
obsadzona dyskami SAS, SATA, biblioteka tamowa oraz serwery backupu
z wbudowan przestrzeni dyskow, - sie: zbudowana na
przecznikach 1Gbps i 10Gbps, z wykorzystaniem czenia portów w grupy
oraz z zachowaniem redundancji pocze. Dodatkowe uszczegóowienie
realizacji tego wymagania znajduje si w rozdziale 4
IaaS musi zapewni zarzdzanie rodowiskiem storage wikszym ni 10
petabajtów.
IaaS musi zapewni zarzdzanie oraz monitorowanie duej (powyej 10 000
hostów) sieci dla maszyn wirtualnych.
IaaS musi zapewni logiczn agregacj maszyn wirtualnych w grupy
(inaczej strefy/zones)
IaaS musi zapewni podzia na regiony zapewniajc osobn dedykowan
konfiguracj dla compute, storage oraz warstwy sieci (w tym moliwo
obsugi innego typu hypervisora oraz innej konfiguracji/sprztu dla
storage i sieci) dla danego regionu. Region musi zapewni take
osobny API endpoints, wspierajc zarazem wspólne uwierzytelnianie
uytkowników w oparciu o SSO oraz wspólny panel administracyjny dla
wszystkich regionów.
IaaS musi zapewni definiowanie domylnego hypervisor dla maszyn
wirtualnych (cloud/vps) uruchamianych w danej grupie (w danej
strefie/zone).
IaaS musi zapewni wiele organizacji (multitenant).
IaaS musi zosta skonfigurowany w trybie wysokiej dostpnoci
(High-Availability) - w szczególnoci dotyczy to kadego komponentu
sucego do zarzdzania i monitorowania infrastruktury IaaS.
IaaS musi zapewni pen kontrol kadego aspektu funkcjonalnego za
pomoc API.
IaaS musi wspiera pluginy dla kadej warstwy architektury (compute,
storage, network) umoliwiajce rozszerzanie funkcjonalnoci danej
warstwy.
IaaS musi zapewni moliwo przydzielenia maszynom wirtualnym od 1 do
co najmniej 128 procesorów wirtualnych.
Licencja IaaS musi zapewnia moliwo cigego rozwoju Systemu przez
Zamawiajcego (wasny zespó), dopuszczalne s dwa podejcia:
przekazanie kodów ródowych do caego Podsystemu IaaS wraz z
przekazaniem autorskich praw majtkowych, bd przekazanie kodów
ródowych do caego Podsystemu IaaS wraz z licencj umoliwiajc rozwój
na wasne potrzeby Zamawiajcego.
Kody ródowe aplikacji musz by przekazane w formie umoliwiajcej
rozwój. Kody ródowe nie mog by zaciemnione (nie mog by poddane
obfuskacji, z ang. obfuscation).
Wraz z kodami ródowymi wymagane jest przekazanie dokumentacji
rozwojowej, w szczególnoci: opis architektury logicznej rozwizania
(moduów), wymaganych i uytych bibliotek i narzdzi, sposób budowania
i dystrybucji aplikacji.
IaaS musi zapewni pen obsug nastpujcych systemów operacyjnych
(zarówno dla serwerów cloud, vps jak i serwerów dedykowanych): GNU
Linux (w tym w szczególnoci: Debian GNU/Linux, RedHat Enterprise
Linux, CentOS, Ubuntu, OpenSUSE, SUSE Enterprise Linux, Oracle
Enterprise Linux), Microsoft Windows Server (2008, 2012 - wersje
standard oraz enterprise), FreeBSD.
IaaS musi obsugiwa systemy operacyjne w najnowszej stabilnej wersji
dostpnej w dniu zakoczenia etapu analizy.
W ramach wdroenia Podsystemu IaaS, Wykonawca musi przygotowa obrazy
dla maszyn wirtualnych (cloud/vps) oraz obrazy do instalacji
serwerów dedykowanych dla wszystkich obsugiwanych systemów
operacyjnych oraz umieci je na usudze biblioteki obrazów (image
template/storage) IaaS.
IaaS musi zapewni zautomatyzowan instalacj/uruchomienie maszyn
wirtualnych (cloud/vps) czy te serwerów dedykowanych bez ingerencji
administratora dla kadego wymaganego systemu operacyjnego.
IaaS musi umoliwi implementacj/wdroenie zarzdzania wszystkimi
funkcjonalnociami Podsystemu przez Podsystemy SelfService oraz
Cloud API.
IaaS musi zapewnia pen integracj z Podsystemem Billing oraz
udostpnia w sposób zautomatyzowany (poprzez API) wszystkie dane
wymagane do prawidowego dziaania i spenienia wszystkich wymaga
Podsystemu Billing.
IaaS musi zapewni moliwo obsugi wielu instancji rónych systemów
operacyjnych na jednym serwerze fizycznym i musi wykorzystywa
sprztow wirtualizacj zasobów.
IaaS musi by niezalene od producenta platformy sprztowej (poprawnie
wspópracowa ze sprztem dostarczanym przez wielu rónych
producentów).
IaaS musi umoliwia przydzielenie wikszej iloci pamici RAM dla
maszyn wirtualnych ni fizyczne zasoby RAM serwera w celu osigniecia
maksymalnego wspóczynnika konsolidacji (tzw. memory
overcommit).
IaaS musi zapewni moliwo monitorowania wykorzystania zasobów
fizycznych infrastruktury wirtualnej jak i parametrów samych maszyn
wirtualnych (cloud/vps) jak te serwerów dedykowanych w trybie
real-time.
IaaS musi zapewni moliwo klonowania systemów operacyjnych wraz z
ich pen konfiguracj i danymi.
IaaS musi umoliwia zastosowanie w serwerach fizycznych dowolnej
iloci procesorów o dowolnej iloci rdzeni.
IaaS musi mie moliwo uruchamiania fizycznych serwerów z centralnie
przygotowanego obrazu poprzez protokó PXE
IaaS musi umoliwia automatyczne równowaenie obcienia serwerów
fizycznych pracujcych jako platforma dla infrastruktury
wirtualnej.
IaaS musi pozwala na definiowanie wzorców (typów) serwerów
wirtualnych (cloud/vps) abstrahujc od parametrów serwerów, np. typ
„Large”, „Medium”, itp.. Wzorce maj wyj naprzeciw oczekiwaniu, aby
uytkownicy/klienci zamawiali podobne konfiguracje maszyn, unikajc
duej fragmentacji zestawianych serwerów. Definicja wzorca serwera
musi uwzgldnia ogólne i szczegóowe parametry, np. dla serwera: CPU
lub vCPU, pami RAM, przestrze dyskowa, adresy IPv4 i IPv6, VLANy,
sieci prywatne, sieci dostpowe VPN.
IaaS musi zapewni uwierzytelnianie uytkowników w oparciu o
SSO.
IaaS musi zapewni zarzdzanie uprawnieniami dla uytkowników w
oparciu o SSO.
IaaS musi pozwala na definiowanie praw dostpu do zasobów wchodzcych
w skad chmury dla ról/uytkowników. Definicje musz obejmowa co
najmniej: dostp do specyficznych zasobów (np. stref, sieci),
maksymalne liczby poszczególnych typów zasobów (CPU, serwery, pami,
przestrze dyskowa, sieci, adresy IP, VPN).
IaaS musi pozwala na definiowanie Usug na potrzeby budowania oferty
Usug zachowujc peny cykl ycia Usugi: • rejestracj Usugi •
autoryzacj Usugi • zamawianie i akceptacja Usugi • rezerwacja
zasobów • uruchamianie Usugi • modyfikacje parametrów • zarzdzanie
Usugami • rezygnacja z Usugi • zwalnianie zasobów.
IaaS musi pozwala na przypisanie przygotowanych modeli kosztów do
poszczególnych zasobów i ról/uytkowników.
IaaS musi umoliwia zdefiniowanie maksymalnej iloci jednostek do
wykorzystania w ramach danej Usugi (np. 10GB transferu danych dla
danego serwera cloud/vps).
IaaS musi wspiera limitowanie wszystkich zasobów sprztowych
przydzielonych do danej instancji wirtualnej.
Szczegóowe wymagania dla wdroenia warstwy/Usugi chmury
obliczeniowej (compute)
IaaS musi zapewni wsparcie nastpujcej listy hypervisor: Microsoft
Hyper-V, Citrix XenServer, Xen, KVM, VMWware ESXi, LXC, QEMU,
Docker, Baremetal (czyli kontrol maszyny fizycznej analogicznie jak
w przypadku maszyny wirtualnej).
IaaS dla nastpujcej grupy hypervisorów musi zapewni operacje:
uruchomienia, restartu i zatrzymania: LXC, Baremetal, Docker.
IaaS dla nastpujcej grupy hypervisorów musi zapewni nastpujce
operacje dla maszyny wirtualnej dziaajcej pod kontrol danego
hypervisora: uruchomienia, restartu, zatrzymania, resize (zmiana
parametrów maszyny wirtualnej), suspend, reasume: Xen, KVM, QEMU,
Hyper-V, ESXi.
IaaS musi umoliwia przenoszenia maszyn wirtualnych (cloud/vps) w
czasie ich pracy (bez zatrzymania dziaania) pomidzy serwerami
fizycznymi (tzw. live migration), dla nastpujcych Hypervisorów:
KVM, XEN, XenServer, Hyper-V, QEMU.
IaaS musi umoliwia instancjonowanie maszyn wirtualnych cloud/vps
zapewniajc automatyczne skalowanie liczby procesorów i pamici
RAM.
Instancje maszyn wirtualnych cloud/vps musz mie moliwo rozliczania
w cyklu minutowym.
IaaS musi udostpni dla maszyn wirtualnych (vps/cloud) zdalny
tryb/system rescue czyli system awaryjnego dostpu do serwera w celu
zlokalizowania i usunicia usterek.
Szczegóowe wymagania dla wdroenia warstwy/Usugi serwery
dedykowane
IaaS musi udostpnia w sposób zautomatyzowany zdaln konsol
zarzdzania sprztem dla klientów kocowych (uytkowników) - czyli
zdalna klawiatura, ekran i mysz, które pozwalaj na dostp do ekranu
klawiszy/myszy serwera za pomoc bezpiecznego poczenia.
IaaS musi udostpni dla serwerów dedykowanych zdalny tryb/system
rescue czyli system awaryjnego dostpu do serwera w celu
zlokalizowania i usunicia usterek.
IaaS musi umoliwia zdalny restart serwera dedykowanego dla maszyn
dedykowanych.
IaaS musi udostpni moliwo zdalnego wyczenia i ponownego
uruchomienia serwera w dowolnej chwili.
IaaS dla serwerów dedykowanych musi udostpni poza jdrem
dostarczanym domylnie na dysku twardym, moliwo uruchomienia maszyny
z sieci z jdrem przygotowanym przez Zamawiajcego lub Wykonawc
(uruchomienie serwera dedykowanego z innym jdrem po sieci).
Szczegóowe wymagania dla wdroenia warstwy/Usugi danych
(storage)
IaaS musi wiadczy usug repozytorium obrazów maszyn wirtualnych
(image storage).
IaaS musi zapewni nastpujce typy obrazów dyskowych: raw, vhd, vmdk,
vdi, qcow2.
IaaS musi umoliwia szyfrowanie dysków systemów wirtualnych pod jego
kontrol. Hasa powinny by nadawane przez uytkownika/klienta
platformy IaaS za pomoc: dedykowanych funkcjonalnoci SelfService,
API bd interfejsu CLI.
Wdroenie IaaS musi obejmowa wdroenie Usugi block storage dla
Klientów (udostpnianie urzdze blokowych rozpoznawane przez system
operacyjny jako dysk).
Usuga block storage musi umoliwia instancjonowanie przestrzeni
dyskowych o rozmiarze min. 50 TB automatycznie podczanych do
systemu operacyjnego (oczywicie ograniczonych fizyczn przestrzeni
dostpn przez oferowany sprzt storage).
Usuga block storage musi umoliwia zmian rozmiaru (powikszanie i
zmniejszanie) przestrzeni dyskowej.
IaaS musi wspiera protokoy dostpowe iSCSI, FC oraz RADOS Block
Device.
Wdroenie IaaS musi obejmowa wdroenie object storage, który musi
zosta zaimplementowany z uyciem protokou RADOS Object Storage w
celu zapewnienia kompatybilnoci z usug Amazon S3.
Usuga object storage musi umoliwia zapis plików i obiektów o
rozmiarze nie mniejszym ni 16TB.
Usuga object storage musi zapewnia mechanizm autoryzacji
dostpu.
Transmisja obiektów z usugi object storage musi by moliwa za pomoc
szyfrowanego poczenia.
Szczegóowe wymagania dla wdroenia warstwy/Usugi sieci
(networking)
IaaS musi zapewnia tworzenie wirtualnych sieci prywatnych
(wirtualna prywatna chmura) pomidzy maszynami wirtualnymi,
serwerami dedykowanymi danego klienta oraz w ramach instancji danej
aplikacji PaaS - implementacja Usugi Cloud Private Network (bd
inaczej Private Network as a Service).
IaaS musi zapewnia kontrolowanie sieci na warstwie drugiej modelu
OSI.
IaaS musi zapewni automatycznie nadawanie prywatnej adresacji: IPv4
oaz IPv6 oraz publicznej adresacji IPv4 oraz IPv6 dla wszystkich
Usug obsugiwanych przez IaaS. W przypadku standardu IPv6 - jeeli
oferowane rozwizanie nie obsuguje na etapie skadania oferty tej
funkcjonalnoci, musi oferowa j na etapie realizacji Projektu.
IaaS musi zapewni usug IP failover, polegajc na moliwoci
przenoszenia publicznych adresów IP midzy rónymi instancjami
Usug.
IaaS musi zapewni Load Balancer as a Service dla kadego Klienta.
Usuga ta powinna zapewnia tworzenie dowolnej liczby instancji load
balancera na poziome: TCP, UDP, HTTP, HTTPS oraz nastpujce
algorytmy load balancingu: Round Robin Wagowany Round Robin
(umoliwiajcy okrelenie wagi dla kadego node), Random losowy,
Preferowana najmniejsza liczba pocze - który bdzie powodowa
kierowanie ruchu na node z najmniejsz liczb pocze, Wagowany
najmniejsza liczba pocze - analogiczny do preferowana najmniejsza
liczba pocze, natomiast pozwalajcy przypisa wagi do poszczególnych
node. Usuga load balancing musi zapewnia take zarzdzanie sesj
uytkownika (session persistance): source IP - zarzdzanie sesj za
pomoc ledzenia adresu ródowego w celu okrelenia node docelowego
oraz HTTP Cookie - ledzenie sesji za pomoc HTTP cookies (jedynie
dla HTTP load balancing). Dodatkowo musi umoliwi zarzdzanie
monitoringiem oraz opcjami automatycznego podczania/odczania load
balancowanych nodów (interwa weryfikacji nodów, liczba prób,
timeout).
IaaS musi zapewni terminacj SSL na load balancerach.
IaaS musi zapewni Usug: Firewall as a Service dla kadego Klienta.
Jeeli oferowane rozwizanie nie obsuguje na etapie skadania oferty
tej funkcjonalnoci, musi oferowa j na etapie realizacji
Projektu.
IaaS musi zapewni moliwo konfiguracji certyfikatu SSL na
poszczególnych instancjach load balancerów.
IaaS musi zapewni Usug: VPN as a Service (VPNaaS - VPN
Site-to-Site) umoliwiajc tworzenie i zarzdzanie dedykowanych sieci
VPN do sieci kadego z Klientów (zarzdzanych przez Klientów) za
pomoc: ipsec VPN. Wykorzystana technologia musi umoliwia poczenie
si do sieci VPN darmowymi, wbudowanymi w system operacyjny bd open
source narzdziami (klientami) IPSEC dostpnymi na nastpujce systemy
operacyjne: GNU Linux, w szczególnoci: Debian GNU/Linux (Wheezy i
nowszy), Fedora Linux (18 i nowsza), OpenSUSE (12 lub nowszy),
Ubuntu Linux (13.10 lub nowszy), Windows 7 (i nowszy), Mac OS X
(10.8 i nowszy). IaaS musi zapewnia take automatyczne generowanie
plików konfiguracyjnych dla wybranego narzdzia ustalonego wspólnie
z Zamawiajcym na etapie analizy.
IaaS musi zapewni segmentacj VLAN sieci Klienta.
Load balancery zarzdzane przez IaaS musz mie moliwo konfigurowania
przekazywanych nagówków HTTP.
IaaS musi zapewni moliwo zarzdzania konfiguracj Two-Way SSL na load
balancerach.
W przypadku wczenia usugi two-way ssl na load balancerze, IaaS musi
zapewni konfiguracj przekazywania nagówków certyfikatów SSL klienta
nawizujcego poczenie (np. pola Common Name, email itd).
IaaS musi zapewnia moliwo definiowania, które z Usug (np. serwerów
cloud bd dedykowanych) maj by podczone do load balancer.
IaaS musi zapewnia zarzdzanie reguami firewall dla pojedynczego
serwera cloud/vps/dedykowanego jak i caych sieci prywatnych i
publicznych klienta. Jeeli oferowane rozwizanie nie obsuguje na
etapie skadania oferty tej funkcjonalnoci, musi oferowa j na etapie
realizacji Projektu.
IaaS musi zapewni rezerwacj i przydzielanie zasobów jak równie ich
rozliczanie (zbieranie metryk udostpnianych Podsystemowi Biling): *
Wirtualnych w oparciu o systemy wirtualizacji zasobów, z moliwoci
definicji parametrów, w tym: - vCPU – ilo - RAM – ilo - Storage -
ilo wg typów storage - IOPS – ilo - Pasmo (gwarantowane,
niegwarantowane) - Transfer danych - ilo - wewntrz Usug - do sieci
Internet - z sieci Internet - VLAN - ilo - Adresy IP publiczne IPv4
oraz IPv6 - ilo - Load Balancer - ilo (wraz z typami zarzdzania
sesji oraz terminacji SSL) - Firewall - ilo - Sieci prywatne - ilo
- instancje VPN - ilo oraz typ * Fizycznych bez wzgldu na
producenta, w tym: - serwerów o zdefiniowanych parametrach -
wolumenów dyskowych - wydzielonych - przydzielanych dynamicznie
(integracja z storage) - Sieci prywatne - ilo - instancje VPN - ilo
oraz typ - Firewall - ilo - Load Balancer - ilo (wraz z typami
zarzdzania sesji oraz terminacji SSL) - Adresy IP publiczne IPv4
oraz IPv6 – ilo.
Szczegóowe wymagania dla panelu administracyjnego i zarzdzania
przez Zamawiajcego IaaS
IaaS musi zapewni centralny interfejs administracyjny, umoliwiajcy
zmian kadego parametru konfiguracyjnego za pomoc dedykowanego
interfejsu WEB (cienki klient).
Interfejs administracyjny IaaS musi zapewni funkcjonalno
wersjonowania parametrów konfiguracyjnych (warto, dat wartoci,
osob/administratora, która wprowadzia warto, unikalne ID dla
zmiany, komentarz dla wprowadzonych zmian) wraz z przywracaniem
wybranej wersji parametru konfiguracyjnego z poziomu panelu.
Panel administracyjny IaaS musi zapewni moliwo zdefiniowania
poziomów akceptacji wprowadzanych zmian.
Interfejs administracyjny IaaS musi zapewni wizualizacj zmian w
konfiguracji, uwzgldniajc: - system/serwer/Usug, której zmiana
dotyczy, - dat powstania zmiany - osob, która dokonaa zmiany, -
diff w postaci graficznej reprezentujcy zmian w stosunku do
poprzednich zmian, - komentarz dot. danej zmiany. Po akceptacji
zmiany musi nastpi automatyczne wdroenie zaakceptowanej
konfiguracji za pomoc mechanizmu orkiestrujcego
(provisioning).
Panel administracyjny musi zapewni mechanizm ról i uprawnie, który
w szczególnoci musi zapewni uprawnienia: - wprowadzanie zmian w
plikach konfiguracyjnych danego zasobu IaaS, - nadawanie uprawnie
do wprowadzania zmian dla caej grupy, - nadawanie uprawnie do
uruchamiania danych konfiguracji na danym serwerze, usudze,
systemem - naley rozróni fakt wprowadzania oraz uruchamiania danych
konfiguracji.
Panel administracyjny musi w trybie real-time wizualizowa postp jak
i operacje (komunikaty usug wprowadzajcych zmiany) wykonywane
podczas wprowadzanych zmian.
Interfejs administracyjny musi zapewni powiadomienie (notyfikacj)
wybranych administratorów o fakcie pojawienia si konfiguracji
gotowych do wdroenia (zarzdzanie grupami zgodnie z wymaganiami dla
wszystkich Podsystemów odbywa bdzie si przez LDAP).
Notyfikacje musz by wysyane na adresy email administratorów.
Treci komunikatów bd mogy by edytowane za pomoc formularza na
stronie Podsystemu i musz by zapisywane jako szablony.
Panel administracyjny musi umoliwi wywietlanie na ywo logów
wszystkich wykonywanych operacji.
Panel musi udostpnia moliwo przeszukiwania i filtrowania logów
wykonywanych operacji z uwzgldnieniem uprawnie do nich.
Panel administracyjny musi udostpnia moliwo rollback (przywrócenia
poprzedniego stanu) - czyli uruchomienia konfiguracji,
instalacji/aktualizacji poprzedniej wersji z systemu kontroli
wersji.
Panel administracyjny musi umoliwia przetestowanie wprowadzonych
zmian w konfiguracji z wykorzystaniem rodowiska integracyjnego
zbudowanego w ramach Projektu.
Panel administracyjny musi zapewnia moliwo zarzdzania i
monitorowania Usug IaaS wszystkich klientów (oraz ich
parametrów).
21. PaaS
………………………………………………………………………………………………………………………………………………………….
………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………………………………......
………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………….…………………………………
PaaS musi stanowi przyjazne, elastyczne, skalowalne i bezpieczne
rodowisko dla aplikacji SaaS.
PaaS musi zapewni: • cykl ycia aplikacji • pakiety deploymentowe
(Platform Deployment Package) • zasoby (Resources) zgodnie ze
specyfikacj Cloud Application Mangement for Platforms
(https://www.oasis-open.org/committees/download.php/47278/CAMP-v1.0.pdf
).
Licencja PaaS musi zapewnia moliwo cigego rozwoju Systemu przez
Zamawiajcego (wasny zespó), dopuszczalne s dwa podejcia:
przekazanie kodów ródowych do caego Podsystemu PaaS wraz z
przekazaniem autorskich praw majtkowych, bd przekazanie kodów
ródowych do caego Podsystemu PaaS wraz z licencj umoliwiajc rozwój
na wasne potrzeby Zamawiajcego.
Kody ródowe aplikacji musz by przekazane w formie umoliwiajcej
rozwój. Kody ródowe nie mog by zaciemnione (nie mog by poddane
obfuskacji, z ang. obfuscation).
Wraz z kodami ródowymi wymagane jest przekazanie dokumentacji
rozwojowej, w szczególnoci: opis architektury logicznej rozwizania
(moduów), wymaganych i uytych bibliotek i narzdzi, sposób budowania
i dystrybucji aplikacji.
PaaS musi integrowa si bezporednio z IaaS oraz wykorzystywa
infrastruktur zarzdzan przez IaaS w celu zarzdzania, monitorowania
oraz automatycznego skalowania rodowiska IaaS.
Kada instancja aplikacji bd bazy danych uruchamianej na Podsystemie
PaaS musi dziaa na dedykowanym kontenerze w oparciu o wirtualizacj
na poziomie systemu operacyjnego GNU/Linux (waciwy system
operacyjny zostanie wybrany i uzgodniony z Zamawiajcym podczas
etapu analizy).
PaaS musi zapewni automatyzacj zarzdzania, skalowania (w tym
auto-skalowanie) i monitorowania rodowiska IaaS dla serwerów
aplikacyjnych, baz danych przeznaczonych dla aplikacji
Klienta.
PaaS musi zapewni automatyzacj zarzdzania, skalowania (w tym
auto-skalowanie) i monitorowania osadzonych na nim aplikacji oraz
baz danych.
PaaS musi zapewni funkcjonalno konfiguracji regu auto-skalowania
dla osadzanych aplikacji oraz baz danych.
PaaS musi zapewni automatyczny provisioning, monitoring i
zarzdzanie rodowisk aplikacyjnych oraz bazodanowych za pomoc
Podsystemu SelfService.
PaaS musi zapewni automatyczny provisioning, monitoring i
zarzdzanie rodowisk aplikacyjnych oraz bazodanowych za pomoc
API.
PaaS musi zapewni automatyczny provisioning, monitoring i
zarzdzanie rodowisk aplikacyjnych oraz bazodanowych za pomoc
dedykowanej aplikacji CLI.
PaaS musi zapewni automatyczny provisioning i zarzdzanie rodowisk
aplikacyjnych oraz bazodanowych za pomoc systemu VCS (system
kontroli wersji) GIT.
PaaS musi posiada architektur moduow oraz zapewni wsparcie wielu
jzyków programowania, w szczególnoci nastpujcych jzyków: Java,
Python, PHP. Zamawiajcy piszc "zapewni wsparcie" ma na myli umoliwi
uruchamianie, zarzdzanie, monitoring oraz auto-skalowanie aplikacji
napisanych w danym jzyku programowania.
PaaS musi zapewni wsparcie wielu wersji danego jzyka oprogramowania
(dana aplikacja moe dziaa na wybranej wersji danego jzyka
oprogramowania).
PaaS musi zapewni wsparcie wielu wersji frameworków/bibliotek
danego jzyka oprogramowania (dana aplikacja moe dziaa na wybranej
wersji danego framework/biblioteki oprogramowania).
Architektura PaaS powinna w przyszoci (bez jej modyfikacji)
umoliwia rozszerzanie funkcjonalnoci Podsystemu o kolejne jzyki
programowania, frameworki, systemy bazodanowe a take umoliwia
proste (za pomoc moduów/pluginów) rozszerzenie Podsystemu o nowe
technologie, narzdzia i usugi (np. rozproszonych i asynchronicznych
systemów zarzdzania kolejkami zada)
Architektura PaaS musi zapewni jego rozszerzenie o wsparcie nowych
bibliotek/frameworków programowania danego jzyka. Zamawiajcy piszc
"zapewni wsparcie" ma na myli umoliwi uruchamianie, zarzdzanie,
monitoring oraz auto-skalowanie aplikacji napisanych w danym
framework/bibliotece danego jzyku programowania.
Architektura PaaS musi zapewni jego rozszerzenie o wsparcie nowych
Usug bazodanowych (w tym usugi bazodanowe SQL i noSQL). Zamawiajcy
piszc "zapewni wsparcie" ma na myli umoliwi uruchamianie (w tym
tworzenie odpowiedniej schemy oraz import wskazanych danych),
zarzdzanie, monitoring oraz auto-skalowanie instancji baz danych w
oparciu o dany system bazodanowy oraz moliwo automatycznego
konfigurowania aplikacji dziaajcej pod kontrol Podsystemu PaaS aby
wykorzystywaa dan instancj bazy danych.
Musi by dostarczona dokumentacja oraz przykad (szablon) w jaki
sposób tworzy moduy/rozszerzenia PaaS w celu zapewnienia wsparcia
dla kolejnych (nie obsugiwanych jeszcze) jzyków
programowania.
Musi by dostarczona dokumentacja oraz przykad (szablon) w jaki
sposób tworzy moduy/rozszerzenia PaaS w celu zapewnienia wsparcia
przykadowego framework dla danych jzyków programowania.
Musi by dostarczona dokumentacja oraz przykad (szablon) w jaki
sposób tworzy moduy/rozszerzenia PaaS w celu zapewnienia wsparcia
przykadowego serwera aplikacyjnego dla danego
jzyka/framework.
Musi by dostarczona dokumentacja oraz przykad (szablon) w jaki
sposób tworzy moduy/rozszerzenia PaaS w celu zapewnienia wsparcia
dla kolejnych (nie obsugiwanych jeszcze) jzyków systemów baz
danych.
PaaS musi zapewni wsparcie nastpujcych frameworków jzyka Java:
Sprint, Play!.
PaaS musi zapewni wsparcie nastpujcych frameworków jzyka Python:
Django, Flask.
PaaS musi zapewni wsparcie nastpujcych frameworków jzyka PHP:
CakePHP, Symphony.
PaaS musi zapewni wsparcie nastpujcych serwerów aplikacyjnych dla
jzyka Java: JBoos, Tomcat.
PaaS musi zapewni wsparcie nastpujcych serwerów WSGI jzyka Python:
Gunicorn, uWSGI.
PaaS musi zapewni wsparcie nastpujcych frameworków jzyka PHP:
CakePHP, Symphony.
PaaS musi zapewni wsparcie uruchamiania aplikacji jzyka PHP za
pomoc oprogramowania: Apache2 wraz z mod_php oraz za pomoc PHP
FastCGI Process Manager (FPM) wraz z proxy NGINX.
PaaS musi zapewni wsparcie dla uruchamiania aplikacji jzyka PHP na
wydzielonym koncie uytkownika, przypisanym do wirtualnego hosta
(mechanizm SuExec).
PaaS musi zapewni wsparcie nastpujcej platformy bazodanowej SQL:
PostgreSQL, MySQL.
PaaS musi zapewni wsparcie nastpujcej platformy bazodanowej noSQL:
MongoDB.
PaaS musi zapewnia pen automatyzacj provisioningu i deploymentu
aplikacji automatycznie konfigurujc aplikacj do dziaania.
PaaS musi zapewnia pen automatyzacj provisioningu i deploymentu
aplikacji automatycznie konfigurujc i podczajc baz danych aplikacji
oraz sam aplikacj z baz danych.
PaaS musi zapewni pen kontrol kadego aspektu funkcjonalnego za
pomoc API.
PaaS musi zapewnia moliwo dostarczenia metryk dla Podsystemu Biling
w celu rozliczania aplikacji dziaajcych na rodowisku PaaS w modelu
Pay as you go - czyli za faktycznie wykorzystane zasoby (CPU, RAM,
przestrze dyskowa, I/O, wykorzystanie (transfer) danych wyjciowych,
wykorzystanie (transfer) danych wejciowych, liczba instancji, czas
dziaania, liczba obsuonych pocze).
Musi by stworzona kompleksowa dokumentacja Podsystemu PaaS wraz z
przykadami uycia dla kadego jzyka, framework oraz bazy
danych.
Musz by dostarczone szkieletowe/przykadowe aplikacje dla kadego
jzyka i framework (w poczeniu z kad baz danych) w celu uatwienia
bootstrapowania nowych aplikacji.
Dokumentacja API oraz przykady aplikacji musz by przygotowane w
jzyku polskim i angielskim.
PaaS musi umoliwia zdefiniowanie w dowolnym momencie liczb
instancji danej aplikacji. Zmiana liczby instancji musi powodowa
automatyczne uruchomienie bd wyczenie danej instancji.
W przypadku zdefiniowania (automatycznie podczas skalowania bd
rcznie) drugiej bd kolejnej instancji danej aplikacji, musi by
automatycznie podniesiona instancja load balancer'a oraz musz by
podczone do niego wszystkie instancje aplikacji. Innym moliwym
sposobem realizacji jest uruchamianie instancji load balancer od
razu dla kadej nowej aplikacji a nastpnie podczanie do niego
kolejnych instancji aplikacji.
Musi by moliwe dostarczenie definicji uruchomienia aplikacji na
rodowisku PaaS (w tym bazy danych) w jednym pliku konfiguracyjnym
doczonym do róde aplikacji - tzw. plik Manifestu.
Podczas uruchamiania instancji aplikacji na rodowisku, PaaS
powinien na podstawie pliku Manifestu w sposób zautomatyzowany
wykry typ uruchamianej aplikacji (jzyk, framework).
Plik Manifestu musi umoliwia skonfigurowanie typu aplikacji (jzyk
oraz wersja jzyka, framework oraz jego wersja, sposób obsugi
instancji danej aplikacji), typ bazy danych, inicjalne dane do
wczytania do bazy, liczb instancji aplikacji, liczb instancji baz
danych, sposób dziaania load balancera (w szczególnoci sesji HTTP),
konfiguracj SSL load balancera, nazw domeny aplikacji, port TCP/IP
(domylnie 80).
Plik Manifestu musi by plikiem tekstowym.
Plik Manifestu musi by w jednym z formatów: YAML, JSON.
Musi by moliwo zalogowania si za pomoc SSH na kontener, na którym
dziaa dana instancja aplikacji.
W przypadku uruchomienia wicej ni jednej instancji danej aplikacji
PaaS (maksymalnie 64 instancje) musi zapewni poprawn obsug sesji
uytkowników oraz wspódzielonych zasobów (np. danych na
dyskach).
W przypadku uruchomienia wicej ni jednej instancji danej aplikacji
PaaS (maksymalnie 64 instancje) musi zapewni automatyczne
instancjonowanie sieci prywatnej (wirtualna prywatna chmura -
private cloud network) oraz instancjonowanie dostpu do teje sieci
prywatnej za pomoc instancji VPN (instancja Usugi VPN as a
Service).
Szczegóowe wymagania dla panelu administracyjnego i zarzdzania
przez Zamawiajcego PaaS
PaaS musi zapewni centralny interfejs administracyjny, umoliwiajcy
zmian kadego parametru konfiguracyjnego za pomoc dedykowanego
interfejsu WEB (cienki klient).
Interfejs administracyjny PaaS musi zapewni funkcjonalno
wersjonowania parametrów konfiguracyjnych (warto, dat wartoci,
osob/administratora, która wprowadzia warto, unikalne ID dla
zmiany, komentarz dla wprowadzonych zmian) wraz z przywracaniem
wybranej wersji parametru konfiguracyjnego z poziomu panelu.
Panel administracyjny PaaS musi zapewni moliwo zdefiniowania
poziomów akceptacji wprowadzanych zmian.
Interfejs administracyjny PaaS musi zapewni wizualizacj zmian w
konfiguracji, uwzgldniajc: - aplikacj/system/serwer/Usug, której
zmiana dotyczy, - dat powstania zmiany - osob, która dokonaa
zmiany, - diff w postaci graficznej reprezentujcy zmian w stosunku
do poprzednich zmian, - komentarz dot. danej zmiany. Po akceptacji
zmiany musi nastpi automatyczne wdroenie zaakceptowanej
konfiguracji za pomoc mechanizmu orkiestrujcego
(provisioning).
Panel administracyjny musi zapewni mechanizm ról i uprawnie, w
szczególnoci nastpujce uprawnienia: - wprowadzanie zmian w plikach
konfiguracyjnych danego zasobu PaaS, - nadawanie uprawnie do
wprowadzania zmian dla caej grupy, - nadawanie uprawnie do
uruchamiania danych konfiguracji na danym serwerze, usudze,
systemie - naley rozróni fakt wprowadzania oraz uruchamiania danych
konfiguracji.
Panel administracyjny musi w trybie real-time wizualizowa postp jak
i operacje (komunikaty usug wprowadzajcych zmiany) wykonywane
podczas wprowadzanych zmian.
Interfejs administracyjny musi zapewni powiadomienie (notyfikacj)
wybranych administratorów o fakcie pojawienia si konfiguracji
gotowych do wdroenia (zarzdzanie grupami zgodnie z wymaganiami dla
wszystkich Podsystemów odbywa bdzie si przez LDAP).
Notyfikacje musz by wysyane na adresy e-mail administratorów.
Treci komunikatów bd mogy by edytowane za pomoc formularza na
stronie Podsystemu i musz by zapisywane jako szablony.
Panel administracyjny musi umoliwi wywietlanie na ywo logów
wszystkich wykonywanych operacji.
Panel musi udostpnia moliwo przeszukiwania i filtrowania logów
wykonywanych operacji z uwzgldnieniem uprawnie do nich.
Panel administracyjny musi udostpnia moliwo rollback (przywrócenia
poprzedniego stanu) - czyli uruchomienia konfiguracji,
instalacji/aktualizacji poprzedniej wersji z systemu kontroli
wersji.
Panel administracyjny musi umoliwia przetestowanie wprowadzonych
zmian w konfiguracji z wykorzystaniem rodowiska integracyjnego
zbudowanego w ramach Projektu.
Panel administracyjny musi zapewnia moliwo zarzdzania i
monitorowania Usug PaaS wszystkich Klientów (oraz ich
parametrów)
22. Cloud API
………………………………………………………………………………………………………………………………………………………….
………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………………………………......
………………………………………………………………………………………………………………………………………………………….
…………………………………………………………………………………………………………….……………………………………………
Wymagana funkcjonalno:
Oferowana funkcjonalno:
Cloud API musi zapewni warstw abstrakcji, która pozwoli w spójny,
atwy do wykorzystania sposób udostpni wewntrzne interfejsy API
wszystkich Podsystemów oraz funkcjonalnoci wchodzcych w skad
Systemu dla uytkowników zewntrznych - w szczególnoci musi udostpnia
przez API funkcjonalnoci dla Klientów wszystkich Usug opartych o
IaaS, PaaS, informacje nt. rozlicze oraz faktur (Billing) oraz pen
obsug konta Klienta (organizacji Klienta) w ramach Podsystemu
(SSO).
Cloud API musi realizowa wymagania Rozporzdzenia Ministra Nauki i
Informatyzacji z dnia 19 padziernika 2005 r. w sprawie testów
akceptacyjnych oraz badania oprogramowania interfejsowego.
Wymagane jest dostarczenie dokumentacji Cloud API wraz z przykadami
dla kadej metody (w jzyku angielskim).
Musz by dostarczony opis wszystkich kodów oraz statusów odpowiedzi
kadej metody API (w jzyku angielskim).
Udostpniany endpoint API musi by zabezpieczony certyfikatem SSL
(dostarczonym przez Zamawiajcego).
Cloud API powinno stanowi spójny interfejs API - a zatem, jeeli
Wykonawca planuje wdroy Podsystemy, które posiadaj róne typy danych
w wywoaniach API, Cloud API musi zapewni jeden wybrany typ danych
dla wszystkich wywoa.
Cloud API oprócz endpointów API musi dostarczy aplikacj/narzdzie
dziaajce w linii polece (CLI), instalowane przez uytkownika na jego
komputerze i dziaajce na najpopularniejszych systemach operacyjnych
(Linux, Windows 7 (i nowsze), Mac OS X 10.8 (i nowszy), FreeBSD),
zapewniajce pen funkcjonalno Cloud API z linii polece (metody
powinny by odwzorowane w odpowiednich argumentach i opcjach).
Aplikacja taka umoliwi np. administratorom bd developerom wykonywa
operacje na platformie bez potrzeby integracji z API a za pomoc
gotowego narzdzia, które mona uy/wykorzysta we wasnych
aplikacjach/skryptach. Aplikacja ta jest aplikacj CLI pozwalajc
zarzdza i monitorowa (jak i weryfikowa rozliczenia) wszystkich Usug
dostarczanych w ramach Systemu i stanowi kolejny (oprócz
SelfService i API) interfejs komunikacji z platform.
Cloud API musi by zintegrowane z rozwizaniem Apache
DeltaCloud.
Cloud API w przypadku obsugi klienta/uytkownika danego Partnera
musi ukry metody dot. rozlicze, jako e rozliczenia tego typu
klientów (klientów Partnerów) bd dokonywane przez tyche partnerów a
nie Zamawiajcego.
Licencja Cloud API musi zapewnia moliwo cigego rozwoju Systemu
przez Zamawiajcego (wasny zespó), a dopuszczalne s dwa podejcia:
przekazanie kodów ródowych do caego Podsystemu Cloud API wraz z
przekazaniem autorskich praw majtkowych, bd przekazanie kodów
ródowych do caego Podsystemu Cloud API wraz z licencj umoliwiajc
rozwój na wasne potrzeby Zamawiajcego.
Kody ródowe aplikacji musz by przekazane w formie umoliwiajcej
rozwój. Kody ródowe nie mog by zaciemnione (nie mog by poddane
obfuskacji, z ang. obfuscation).
Wraz z kodami ródowymi wymagane jest przekazanie dokumentacji
rozwojowej, w szczególnoci: opis architektury logicznej rozwizania
(moduów), wymaganych i uytych bibliotek i narzdzi, sposób budowania
i dystrybucji aplikacji.
23. SelfService
………………………………………………………………………………………………………………………………………………………….
………………………………………………………………………………………………………………………………………………………….
……………………………………………………………………………………………………………………………………………………......
………………………………………………………………………………………………………………………………………………………….
…………………………………………………………………………………………………………………………………………………………
SelfService musi umoliwi K