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