SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA CZĘŚĆ XIII - POWIAT POLKOWICKI Załącznik A13 Postępowanie prowadzone w trybie przetargu nieograniczonego na:

Shape1

Strona25




SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

CZĘŚĆ XIII - POWIAT POLKOWICKI

Załącznik A13

Postępowanie prowadzone w trybie przetargu nieograniczonego na:



„Zakup, instalacje i konfiguracje sprzętu komputerowego wraz z oprogramowaniem systemowym i bazodanowym oraz dostawa i wdrożenie wybranych e-usług publicznych wraz z budową POK w 23 JST”

w ramach projektu:
„PLATFORMA ELEKTRONICZNYCH USŁUG GEODEZYJNYCH - PEUG”

Działanie 2.1. E-usługi publiczne

Regionalny Program Operacyjny Województwa Dolnośląskiego na lata 2014-2020




Spis Tabel



Spis Ilustracji





  1. DIAGNOZA STANU OBECNEGO

Poniżej przedstawiono analizę stanu obecnego w zakresie zasobów sprzętowo - programowych, które zostaną wykorzystane przy realizacji zamówienia.

    1. System PZGiK

Obecnie w powiecie polkowickim funkcjonuje System PZGiK Ewid2007 (TurboEwid) – Geomatyka Kraków.

Lp.

Powiat

System PZGiK funkcjonujący

w Jednostce do prowadzenia bazy GESUT, BDOT500, EGiB

13

xxxxxxxxxx

Ewid 2007 (TurboEwid) - Geomatyka Kraków

Tabela 1 System PZGiK w PODGiK

EWID2007 firmy Geomatyka Kraków s.c. z desktopowym interfejsem aplikacyjnym TurboEWID oraz sieciowym interfejsem aplikacyjnym WebEWID jest Systemem PZGiK w pełni dostosowanym do najnowszych przepisów wykonawczych Ustawy PGiK. Jest dostosowany do obowiązującego modelu pojęciowego danych oraz do prowadzenia wszystkich zbiorów danych powiatowej części PZGiK (EGiB, RCiWN, BDOT500, GESUT, BDSOG) w postaci jednej zintegrowanej bazy danych. EWID2007 umożliwia eksport i import danych w formatach GML i SWDE oraz własnym natywnym formacie KCD. Umożliwia także aktualizację danych wraz z rejestracją historii zmian na podstawie plików przyrostowych (różnicowych) w formatach: GML i SWDE.

    1. Zasoby sprzętowo-programowe

W ramach realizacji niniejszego zamówienia planuje się wykorzystanie zasobów sprzętowo-programowych. Poniżej przedstawiony został wykaz posiadanych elementów infrastruktury teleinformatycznej, które zostaną wykorzystane przy realizacji zamówienia.

Nazwa powiatu

Rozwiązania bazodanowe

Powiat polkowicki

Oracle

Tabela 2 Silnik bazy danych

    1. Zestawienie wdrożonych e-usług w ramach Systemu PZGiK

Aktualnie w powiecie polkowickim w PODGiK zostały wdrożone głównie e-usługi na 2 poziomie dojrzałości oraz dwie e-usługi na 3 poziomie. Szczegółowy wykaz e-usług przedstawiono w poniższej tabeli:

Lp.

Nazwa e-usługi

Poziom 1

Poziom 2

Poziom 3

Poziom 4

Brak
e-usługi

1

Przyjęcie wniosku o aktualizację informacji zawartych w ewidencji gruntów i budynków zgodnie z art.24 ust.2b pkt.1, ppkt.h - PGiK


x




2

Przyjęcie wniosku o przeprowadzenie aktualizacji klasyfikacji gruntów


x




3

Przyjęcie wniosku o udostępnienie mapy ewidencji gruntów i budynków


x




4

Przyjęcie wniosku o udostępnienie mapy zasadniczej


x




5

Przyjęcie wniosku o udostępnienie rejestrów, kartotek, skorowidzów, wykazów, zestawień tworzonych z baz danych EGiB


x




6

Przyjęcie wniosku o udostępnienie w postaci elektronicznej zbiorów danych zgodnie z art.40a ust.2 pkt 4 a i b - PGiK


x




7

Przyjęcie wniosku o udostępnienie zbiorów danych bazy BDOT500


x




8

Przyjęcie wniosku o udostępnienie zbiorów danych bazy BDSOG


x




9

Przyjęcie wniosku o udostępnienie zbiorów danych bazy EGiB


x




10

Przyjęcie wniosku o udostępnienie zbiorów danych bazy GESUT


x




11

Przyjęcie wniosku o udostępnienie zbiorów danych bazy RCiWN


x




12

Przyjęcie wniosku o ujawnienie lub wykreślenie w EGiB umów dzierżawy


x




13

Przyjęcie wniosku o wydanie wypisu lub wypisu i wyrysu lub wyrysu z ewidencji gruntów i budynków


x




14

Przyjęcie wniosku w sprawie koordynacji usytuowania projektowanych sieci uzbrojenia terenu


x




15

Przyjęcie wniosku w sprawie zgłoszenia lub uzupełnienia pracy geodezyjnej/kartograficznej



x



16

Przyjęcie wniosku zgłoszenia zmian danych ewidencji gruntów i budynków zgodnie z art.22 ust.2 - PGiK


x




17

Uwierzytelnienie dokumentów opracowanych przez wykonawcę prac geodezyjnych/kartograficznych


x




18

Zawiadomienie o wykonaniu zgłoszonych prac geodezyjnych/kartograficznych



x



19

Usługa udostępniania materiałów powiatowego zasobu geodezyjnego i kartograficznego


x




Tabela 3 Aktualny stan e-usług udostępnianych w ramach posiadanego Systemu PZGiK

  1. SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIANIA DLA CZĘSCI XIII

    1. Infrastruktura sprzętowo-programowa

W ramach realizacji projektu Wykonawca zobowiązany jest dostarczyć następujące elementy infrastruktury sprzętowej wraz z oprogramowaniem systemowym i narzędziowym:

Lp.

Nazwa

Ilość

-

-

polkowicki

1.

Serwery bazodanowo - aplikacyjne

1

2.

Macierze dyskowe - 8 dysków

1

3.

Szafy rack 42U

1

4.

Środowiska bazodanowe

1

Tabela 4 Wykaz sprzętu objętego zamówieniem

Miejsce dostarczenia wyżej wymienionych elementów infrastruktury sprzętowej wraz z oprogramowaniem systemowym i narzędziowym:

ul. Św. Xxxxxxxxxx 1,

59-100 Polkowice

    1. Wymagania – parametry techniczne

      1. Architektura serwera bazodanowo - aplikacyjnego

W serwerze należy zastosować mechanizm wirtualizacji, który pozwala na budowę maszyny wirtualnej dla środowiska bazy danych, pracującego w układzie Active / Passive. Poniżej przedstawiono schemat ideowy klastra:

Rysunek 1 Architektura środowiska bazodanowo – aplikacyjnego active/passive. Opracowanie własne.





      1. Wymagania na serwer bazodanowo - aplikacyjny

Identyfikator

WF 1.1

Serwer: Wymaga się, aby serwer był złożony z maszyny w której skład wchodzą co najmniej 2 procesory fizyczne. Wymaga się zachowania poprawności licencjonowania środowisk bazodanowych z dostarczeniem odpowiedniej liczby licencji.


Identyfikator

WF 1.2

Typ obudowy: Obudowa Rack o wysokości max 2U z możliwością instalacji do 8 dysków 2.5" Hot-Plug wraz z kompletem wysuwanych szyn umożliwiających montaż w szafie rack i wysuwanie serwera do celów serwisowych oraz organizatorem do kabli.


Identyfikator

WF 1.3

Serwer musi być dostosowany do parametrów funkcjonującego Systemu PZGiK, ilości gromadzonych danych, liczby transakcji generowanych przez system, zapasu zakładającego wzrost obciążenia w ramach platformy POK.


Identyfikator

WF 1.4

Płyta główna: Wymaga się, aby płyta główna miała możliwość zainstalowania odpowiedniej liczby procesorów.


Identyfikator

WF 1.5

Chipset: Dedykowany przez producenta procesora do pracy w serwerach o odpowiedniej liczbie procesorów.


Identyfikator

WF 1.6

Procesor: Zainstalowana odpowiednia liczba procesorów szesnasto-rdzeniowych klasy x86 dedykowanych do pracy z zaoferowanym serwerem umożliwiających osiągnięcie wyniku min. 1690 punktów w teście SPECint_rate_base2006 dostępnym na stronie xxx.xxxx.xxx dla dwóch procesorów. Należy załączyć wydruk ze strony internetowej potwierdzający osiągniecie wyniku.


Identyfikator

WF 1.7

Serwer musi posiadać zainstalowaną kartę SAS HBA posiadającą 8 zew. portów (dwa złącza typu Mini-SAS HD).


Identyfikator

WF 1.8

Pamięć RAM: Minimum 128GB DDR4 RDIMM min. 2666MT/s, w kościach min. 64GB. Na płycie głównej musi znajdować się minimum 12 slotów przeznaczonych do instalacji pamięci. Płyta główna musi obsługiwać co najmniej 1.5TB pamięci RAM.


Identyfikator

WF 1.9

Zabezpieczenia pamięci RAM: Memory Rank Sparing, Memory Mirror, SDDC lub mechanizmem ECC.


Identyfikator

WF 1.10

Gniazda PCI: Minimum 4 sloty x8 generacji 3.


Identyfikator

WF 1.11

Interfejsy sieciowe: Wbudowane minimum dwa interfejsy sieciowe 1Gb Ethernet w standardzie BaseT oraz minimum dwa interfejsy sieciowe 10Gb Ethernet ze złączami w standardzie BaseT.


Identyfikator

WF 1.12

Dyski twarde:

  • Możliwość instalacji dysków SATA, SAS, SSD.

  • Zainstalowane co najmniej 2x300GB SAS 12Gb/s 10krpm.

  • Możliwość instalacji modułu dedykowanego dla hypervisora wirtualizacyjnego, możliwość wyposażenia modułu w 2 jednakowe nośniki typu flash o pojemności min. 64GB z możliwością konfiguracji zabezpieczenia synchronizacji pomiędzy nośnikami z poziomu BIOS serwera, rozwiązanie nie może powodować zmniejszenia ilości wnęk na dyski twarde.


Identyfikator

WF 1.13

Kontroler RAID: Sprzętowy kontroler dyskowy, posiadający min. 2GB nieulotnej pamięci cache, możliwe konfiguracje poziomów RAID: 0, 1, 5, 6, 10, 50, 60.


Identyfikator

WF 1.14

Wbudowane porty: min. 3 porty USB 2.0, min. 2 porty USB 3.0, min. 4 porty RJ45, min. 1 port VGA, min. 1 port RS232.

Nie dopuszcza się stosowania przejściówek, adapterów oraz rozgałęziaczy i przedłużaczy.


Identyfikator

WF 1.15

Wymagane jest, aby urządzenie posiadało zintegrowaną kartę graficzną umożliwiającą wyświetlanie obrazu w rozdzielczości min. 1920x1200.


Identyfikator

WF 1.16

Wymaga się, aby były zainstalowane redundantne wentylatory z funkcją pozwalająca na wymianę/podłączenie urządzenia bez konieczności wyłączania/restartowania całego systemu (Hot swap).

Wymagany jest nadmiarowy układ chłodzenia (redundancja typu N+1).


Identyfikator

WF 1.17

Wymaga się, aby były zainstalowane min. 2 kontrolery SAS-HBA do nadmiarowego połączenia z macierzą dyskową.


Identyfikator

WF 1.18

Zasilacze: Minimum dwa zasilacze z możliwością wymiany w trakcie pracy (Hot swap).

Wymagany jest nadmiarowy układ chłodzenia (redundancja typu N+1).


Identyfikator

WF 1.19

Wymaga się, aby urządzenie było wyposażone w kartę zarządzającą wraz z oprogramowaniem zarządzającym, niezależną od zainstalowanego na serwerze systemu operacyjnego posiadającą dedykowany port RJ-45 Gigabit Ethernet umożliwiającą:

  • zdalny dostęp do graficznego interfejsu Web karty zarządzającej;

  • zdalne monitorowanie i informowanie o statusie serwera (x.xx. prędkości obrotowej wentylatorów, konfiguracji serwera);

  • szyfrowane połączenie (SSLv3) oraz autentykacje i autoryzację użytkownika;

  • możliwość podmontowania zdalnych wirtualnych napędów;

  • wirtualną konsolę z dostępem do myszy, klawiatury;

  • wsparcie dla IPv6;

  • wsparcie dla SNMP; IPMI2.0, VLAN tagging, Telnet, SSH;

  • możliwość zdalnego monitorowania w czasie rzeczywistym poboru prądu przez serwer;

  • możliwość zdalnego ustawienia limitu poboru prądu przez konkretny serwer;

  • integracja z Active Directory;

  • możliwość obsługi przez dwóch administratorów jednocześnie;

  • wsparcie dla dynamic DNS;

  • wysyłanie do administratora maila z powiadomieniem o awarii lub zmianie konfiguracji sprzętowej;

  • możliwość podłączenia lokalnego poprzez złącze RS-232.;

  • możliwość zarządzania bezpośredniego poprzez złącze USB umieszczone na froncie obudowy;

  • możliwość konfiguracji przepływu powietrza na każdym slocie PCIe, jak również musi posiadać możliwość konfiguracji wyłączania lub włączania poszczególnych wentylatorów;

  • możliwość zablokowania konfiguracji oraz odnowienia oprogramowania karty zarządzającej poprzez jednego z administratorów. Podczas trwania blokady musi być ona wyświetlana dla wszystkich administratorów którzy obecnie korzystają z karty.


Identyfikator

WF 1.20

Wymaga się, aby dostarczono dodatkowe oprogramowanie umożliwiające zarządzanie poprzez sieć i spełniające minimalne wymagania:

  • wsparcie dla serwerów, urządzeń sieciowych oraz pamięci masowych;

  • możliwość zarządzania dostarczonymi serwerami bez udziału dedykowanego agenta;

  • wsparcie dla protokołów– WMI, SNMP, IPMI, Linux SSH;

  • możliwość oskryptowywania procesu wykrywania urządzeń;

  • możliwość uruchamiania procesu wykrywania urządzeń w oparciu o harmonogram;

  • szczegółowy opis wykrytych systemów oraz ich komponentów;

  • możliwość eksportu raportu do CSV, HTML;

  • grupowanie urządzeń w oparciu o kryteria użytkownika;

  • możliwość uruchamiania narzędzi zarządzających w poszczególnych urządzeniach;

  • automatyczne skrypty CLI umożliwiające dodawanie i edycję grup urządzeń;

  • podgląd stanu środowiska;

  • podsumowanie stanu dla każdego urządzenia;

  • szczegółowy status urządzenia/elementu/komponentu;

  • generowanie alertów przy zmianie stanu urządzenia;

  • filtry raportów umożliwiające podgląd najważniejszych zdarzeń;

  • integracja z service desk producenta dostarczonej platformy sprzętowej;

  • możliwość przejęcia zdalnego pulpitu;

  • możliwość podmontowania wirtualnego napędu;

  • kreator umożliwiający dostosowanie akcji dla wybranych alertów;

  • możliwość importu plików MIB;

  • przesyłanie alertów „as-is” do innych konsol firm trzecich;

  • możliwość definiowania ról administratorów;

  • możliwość zdalnej aktualizacji sterowników i oprogramowania wewnętrznego serwerów;

  • aktualizacja oparta o wybranie źródła bibliotek (lokalna, on-line producenta oferowanego rozwiązania);

  • możliwość instalacji sterowników i oprogramowania wewnętrznego bez potrzeby instalacji agenta;

  • możliwość automatycznego generowania i zgłaszania incydentów awarii bezpośrednio do centrum serwisowego producenta serwerów;

  • moduł raportujący pozwalający na wygenerowanie następujących informacji: nr seryjne sprzętu, konfiguracja poszczególnych urządzeń, wersje oprogramowania wewnętrznego, obsadzenie slotów PCI i gniazd pamięci, informacje o maszynach wirtualnych, aktualne informacje o stanie gwarancji, adresy IP kart sieciowych;

  • możliwość automatycznego przywracania ustawień serwera ,kart sieciowych, BIOS, wersji firmware w przypadku awarii i wymiany któregoś z komponentów (w tym kontrolera RAID, kart sieciowych, płyty głównej).


Identyfikator

WF 1.21

Bezpieczeństwo:

  • Wbudowany czujnik otwarcia obudowy współpracujący z BIOS i kartą zarządzającą.


Identyfikator

WF 1.22

Warunki gwarancji:

Gwarancja realizowana w miejscu instalacji sprzętu, z czasem reakcji do następnego dnia roboczego od przyjęcia zgłoszenia, możliwość zgłaszania awarii w trybie 365x7x24 poprzez ogólnopolską linię telefoniczną producenta. W przypadku eskalacji zgłoszenia serwisowego producent jest zobowiązany zapewnić dedykowanego opiekuna technicznego, zdalnie koordynującego prace serwisowe. Zamawiający wymaga dostarczenia przez producenta miesięcznych raportów dotyczących częstotliwości występowania usterek, jakości i terminowości wykonywanych napraw, zaleceń dotyczących instalacji nowych sterowników oraz mikrokodu urządzenia.

Wymaga się zapewnienia możliwość telefonicznego sprawdzenia konfiguracji sprzętowej serwera oraz warunków gwarancji po podaniu numeru seryjnego bezpośrednio u producenta lub jego przedstawiciela.

W ramach gwarancji musi być dostępna ogólnopolska, telefoniczna infolinia/linia techniczna producenta sprzętu, (ogólnopolski numer o zredukowanej odpłatności 0-800/0-801, w ofercie należy podać nr telefonu) w czasie obowiązywania gwarancji na sprzęt i umożliwiająca po podaniu numeru seryjnego urządzenia weryfikację: konfiguracji sprzętowej serwera, w tym model i typ dysków twardych, procesora, ilość fabrycznie zainstalowanej pamięci operacyjnej, czasu obowiązywania i typ udzielonej gwarancji.


Identyfikator

WF 1.23

Dokumentacja użytkownika:

  • Zamawiający wymaga dostarczenia dokumentacji w języku polskim;

  • Oferent zobowiązany jest dostarczyć wraz z ofertą kartę produktową oferowanego serwera umożliwiającą weryfikację parametrów oferowanego sprzętu.


Identyfikator

WF 1.24

Wymagane jest zapewnienie możliwość aktualizacji i pobrania sterowników do oferowanego modelu serwera w najnowszych certyfikowanych wersjach bezpośrednio z sieci Internet za pośrednictwem strony www producenta serwera.


Identyfikator

WF 1.25

Serwer musi posiadać deklarację CE.


Identyfikator

WF 1.26

Oferowany serwer musi posiadać status „Certified for Windows” dla systemów: Microsoft Windows 2012 x64, Microsoft Windows 2012R2 x64, Windows Server 2016 x64.


Identyfikator

WF 1.27

Wymagania na serwerowy system operacyjny znajdują się w części wspólnej SOPZ w rozdziale 8.2 Oprogramowanie systemowe.


      1. Macierz dyskowa – 8 dysków

Identyfikator

WF 2.1

Wymaga się, aby macierz dyskowa posiadała architekturę modułową w zakresie obudowy dla instalacji kontrolerów oraz obsługiwanych dysków, z dopuszczeniem współdzielenia jednego z modułów przez zainstalowane kontrolery i dyski.


Identyfikator

WF 2.2

Typ obudowy: Wymaga się, aby obudowa była dedykowana do zamontowania w szafie RACK 19”, maksymalna wysokość 2U RACK oraz dostarczona, wraz ze wszystkimi elementami niezbędnymi do zamontowania w szafie i organizatorem kabli.

Obudowa musi posiadać widoczne elementy sygnalizacyjne do informowania o stanie poprawnej pracy lub awarii macierzy.


Identyfikator

WF 2.3

Każdy skonfigurowany moduł/obudowa musi posiadać układ nadmiarowy zasilania i chłodzenia zapewniający ciągłą pracę macierzy bez ograniczeń czasowych i wydajnościowych w przypadku utraty nadmiarowości w danym układzie (zasilania lub chłodzenia).


Identyfikator

WF 2.4

Kontrolery macierzy muszą obsługiwać tryb pracy w układzie active-active lub mesh-active lub ALUA. Macierz musi być dostarczona z zainstalowanymi minimum 2 kontrolerami.


Identyfikator

WF 2.5

Wymaga się, aby macierz była wyposażona w minimum 4 porty 12 Gb SAS per kontroler służące do podłączania hostów oraz 4 porty 10GbE lub 16Gb FC.


Identyfikator

WF 2.6

Wymaga się, aby macierz zawierała łącznie minimum 8 dysków 2,5” SAS o pojemności minimum 1800 GB każdy i prędkości obrotowej minimum 10k RPM.


Identyfikator

WF 2.7

Wymagana jest możliwość rozbudowy macierzy (bez wymiany kontrolerów macierzy) do co najmniej 160 dysków twardych.


Identyfikator

WF 2.8

Dwa kontrolery macierzy muszą być wyposażone w przynajmniej 8GB pamięci podręcznej Cache każdy.

W przypadku awarii zasilania dane nie zapisane na dyski, przechowywane w pamięci podręcznej Cache dla zapisów, muszą być zabezpieczone metodą trwałego zapisu na dysk lub nośnik nie wymagający korzystania z podtrzymania jego zasilania.


Identyfikator

WF 2.9

Wymagane jest zapewnienie wsparcia dla grup dyskowych RAID: 0, 1, 5, 6, 10.

Dodatkowo macierz musi posiadać mechanizm tworzenia wirtualnej przestrzeni na minimum 180 dyskach macierzy wraz z wyliczaniem parzystości oraz podwójnej parzystości w celu zabezpieczenia danych. Mechanizm ten musi być przygotowany do optymalizacji procesów odtwarzania dysków pojemnościowych NL-SAS.

Obliczanie sum kontrolnych (kodów parzystości) dla grup dyskowych RAID5 i RAID6 musi być realizowane w sposób sprzętowy przez dedykowany układ w macierzy.


Identyfikator

WF 2.10

Oferowany system dyskowy musi być dostarczony z wstępnie skonfigurowanym RAID 10.


Identyfikator

WF 2.11

Wymaga się, aby macierz nie posiadała pojedynczego punktu awarii, który powodowałby brak dostępu do danych. Musi być zapewniona pełna redundancja komponentów, w tym: kontrolerów, zasilaczy i wentylatorów.

Macierz musi umożliwiać wymianę elementów systemu w trybie „hot-swap”, a w szczególności takich, jak: dyski, kontrolery, zasilacze, wentylatory.

Macierz musi mieć możliwość zasilania z dwóch niezależnych źródeł zasilania – odporność na zanik zasilania jednej fazy lub awarię jednego z zasilaczy macierzy.


Identyfikator

WF 2.12

Wymaga się, aby macierz dyskowa posiadała dedykowane minimum 4 interfejsy RJ-45 Ethernet obsługujące połączenia z prędkością 100Mb/s i 1Gb/s - dla zdalnej komunikacji z oprogramowaniem zarządzającym i konfiguracyjnym macierzy.


Identyfikator

WF 2.13

Każdy kontroler macierzy musi pozwalać na konfigurację interfejsów niezbędnych dla współpracy w sieci IP/FC SAN.

Dla obsługi operacji blokowych I/O w sieci IP/FC SAN kontrolery macierzy muszą wspierać protokoły transmisji: FC, iSCSI, SAS 12G, a ich obsługa odbywa się jednocześnie.


Identyfikator

WF 2.14

Wymaga się, aby macierz obsługiwała - dla interfejsów iSCSI i interfejsów obsługujących protokoły CIFS i NFS - adresacje IP v.4.


Identyfikator

WF 2.15

Oferowany system dyskowy musi się składać z pojedynczej macierzy dyskowej. Za pojedynczą macierz nie uznaje się rozwiązania opartego o wiele macierzy dyskowych (par kontrolerów macierzowych) połączonych przełącznikami SAN lub tzw. wirtualizatorem sieci SAN czy wirtualizatorem macierzy dyskowych.


Identyfikator

WF 2.16

Macierz musi zapewniać możliwość szyfrowania danych. Realizacja procesu szyfrowania i zarządzania kluczem może się odbywać przez kontrolery macierzy lub zewnętrzne urządzenia i oprogramowanie do zarządzania kluczami.

Wszystkie licencje na funkcjonalności muszą być dostarczone na maksymalną pojemność macierzy.


Identyfikator

WF 2.17

Macierz musi wspierać mieszaną konfigurację dysków SAS, NearLine-SAS i SSD w obrębie każdego pojedynczego modułu obudowy pozwalającego na instalacje dysków hot-plug. Model macierzy pozwala na instalację dysków hot-plug w formacie 2,5” i 3,5”.


Identyfikator

WF 2.18

Oprogramowanie do zarządzania musi być zintegrowane z systemem operacyjnym systemu pamięci masowej przy obsłudze transmisji danych protokołami blokowymi (FC, iSCSI, SAS).

Zdalne zarządzanie macierzą musi odbywać się bez konieczności instalacji żadnych dodatkowych aplikacji na stacji administratora.

Wbudowane oprogramowanie macierzy musi obsługiwać połączenia z modułem zarządzania macierzy poprzez szyfrowanie komunikacji protokołami: SSL dla komunikacji poprzez przeglądarkę WWW i protokołem SSH dla komunikacji poprzez CLI.


Identyfikator

WF 2.19

Macierz musi umożliwiać aktualizację oprogramowania wewnętrznego, kontrolerów RAID i dysków bez konieczności wyłączania macierzy i bez konieczności wyłączania ścieżek logicznych FC/iSCSI dla podłączonych serwerów.


Identyfikator

WF 2.20

Macierz musi umożliwiać dokonywanie w trybie on-line (tj. bez wyłączania zasilania i bez przerywania przetwarzania danych w macierzy) operacje: powiększania grup dyskowych, zwiększania rozmiaru woluminu, alokowania woluminu na inną grupę dyskową.


Identyfikator

WF 2.21

Wymaga się, aby macierz posiadała wsparcie dla co najmniej następujących systemów operacyjnych: Microsoft® Windows Server®, Red Hat Enterprise Linux®, Novell SUSE Linux Enterprise Server, Oracle® Solaris, HP HP-UX, IBM AIX.


Identyfikator

WF 2.22

Wymaga się, aby macierz umożliwiała uruchomienie mechanizmów zdalnej replikacji danych - w trybie synchronicznym po FC i asynchronicznym - po protokole iSCSI bez konieczności stosowania zewnętrznych urządzeń konwersji wymienionych protokołów transmisji.

Funkcjonalność replikacji danych musi być zapewniona z poziomu oprogramowania wewnętrznego macierzy. Niniejsza funkcjonalność nie powinna wymagać dostarczenia dodatkowych licencji.


Identyfikator

WF 2.23

Wymaga się, aby macierz miała możliwość obsługi mechanizmów QoS (ang. Quality of Services) czyli nadawania priorytetów obsługi transmisji I/O dla skonfigurowanych hostów, LUN-ów, portów do hostów.


Identyfikator

WF 2.24

Wymaga się, aby macierz umożliwiała rozproszenie alokacji danych dla pojedynczego woluminu LUN na maksymalnej liczbie obsługiwanych dysków HDD.


Identyfikator

WF 2.25

Wymaga się, aby macierz obsługiwała mechanizmy Thin Provisioning czyli przydziału dla obsługiwanych środowisk woluminów logicznych o sumarycznej pojemności większej od sumy pojemności dysków fizycznych zainstalowanych w macierzy. Jeżeli taka funkcjonalność wymaga dodatkowych licencji, to należy je dostarczyć wraz z macierzą dla maksymalnej pojemności dyskowej oferowanej macierzy.


Identyfikator

WF 2.26

Wymaga się, aby model oferowanej macierzy wspierał rozwiązania klasy „wysokiej dostępności”, tj. zapewnienia wysokiej dostępności zasobów dyskowych macierzy dla podłączonych platform software’owych i sprzętowych z wykorzystaniem synchronicznej replikacji danych protokołem FC pomiędzy minimum 2 macierzami. Pod użytym pojęciem „wysoka dostępność zasobów dyskowych” należy rozumieć zapewnienie bezprzerwowego działania środowiska (aplikacja/ system operacyjny/ serwer) podłączonego do macierzy (macierz podstawowa) w przypadku wystąpienia awarii logicznego połączenia z tą macierzą bądź awarii samej macierzy, powodujących dla danego środowiska brak dostępu do zasobów macierzy podstawowej.


Identyfikator

WF 2.27

Wymaga się, aby mechanizm AST lub SSD Cache był obsługiwany przy korzystaniu z co najmniej dwóch dostarczonych technologii dyskowych: SSD z SAS lub SSD z NL-SAS.


      1. Szafy rack 42U

Identyfikator

WF 3.1

Parametry ogólne:

Maksymalny ciężar netto

125 kg

Minimalna nośność (obciążenie dynamiczne)

1000 kg

Minimalna nośność (obciążenie statyczne)

1350 kg

Szerokość

600 mm

Wysokość w szafie

42U

Maksymalna głębokość montażu

915 mm


Identyfikator

WF 3.2

Udogodnienia:

Narzędzia do regulacji obudowy i elementy montażowe w komplecie

TAK

Otwory do prowadzenia kabli z fabrycznie zainstalowanymi listwami szczotkowymi

TAK

Perforowane drzwi przednie o zakrzywionym przekroju zwiększającym powierzchnię wymiany powietrza

TAK

Listwa zasilająca

TAK

Zdejmowalny dach

TAK

Dachowy panel wentylatorowy

TAK


Identyfikator

WF 3.3

Bezpieczeństwo:

Zintegrowane uziemienie elektryczne

TAK

Konstrukcja o podwyższonej stabilności

TAK


Identyfikator

WF 3.4

Normy i standardy:

Klasa ochrony

IP20

TAK

Zgodność:

UL 2416, UL 60950-1

TAK


Identyfikator

WF 3.5

Gwarancja i serwis

Gwarancja fabryczna Producenta

5 lat gwarancji naprawy lub wymiany


    1. Oprogramowanie

      1. Środowiska bazodanowe

Identyfikator

WF 4.1

Wymagane jest, aby licencja na środowisko bazodanowe była bezterminowa do pełnego użytku (typu full use) z 3 letnim wsparciem technicznym.


Identyfikator

WF 4.2

Wymagane jest zapewnienie współpraca z systemem operacyjnym zainstalowanym na serwerze (klastrze) bazodanowo - aplikacyjnym. Wymagana jest niezależność platformy systemowej dla oprogramowania klienckiego/serwera aplikacyjnego od platformy systemowej bazy danych.


Identyfikator

WF 4.3

Wymagane jest, aby oprogramowanie bazodanowe zapewniało możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego.


Identyfikator

WF 4.4

Wymaga się, aby oprogramowanie bazodanowe przetwarzało dane z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.


Identyfikator

WF 4.5

Wymaga się, aby oprogramowanie bazodanowe umożliwiało zagnieżdżanie transakcji – musi istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. Przykładowo – ma być możliwy następujący scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana.


Identyfikator

WF 4.6

Wymaga się, aby oprogramowanie bazodanowe miało wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).


Identyfikator

WF 4.7

Wymaga się, aby była możliwość migracji zestawu znaków bazy danych do Unicode.


Identyfikator

WF 4.8

Wymaga się, aby oprogramowanie bazodanowe umożliwiało redefiniowanie przez klienta ustawień narodowych – symboli walut, formatu dat, porządku sortowania znaków za pomocą narzędzi graficznych.


Identyfikator

WF 4.9

Wymaga się, aby oprogramowanie bazodanowe posiadało funkcję skalowania rozwiązań opartych o architekturę trójwarstwową, tzn.: możliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych.


Identyfikator

WF 4.10

Wymaga się, aby oprogramowanie bazodanowe umożliwiało otworzenie wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych.


Identyfikator

WF 4.11

Wymagane jest wsparcie protokołu XA.


Identyfikator

WF 4.12

Wymaganie jest wsparcie standardu JDBC 3.0.


Identyfikator

WF 4.13

Wymagana jest zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym.


Identyfikator

WF 4.14

Wymaga się, aby motor bazy danych umożliwiał wskazywanie optymalizatorowi SQL preferowanych metod optymalizacji na poziomie konfiguracji parametrów pracy serwera bazy danych oraz dla wybranych zapytań. Musi istnieć możliwość umieszczania wskazówek dla optymalizatora w wybranych instrukcjach SQL.


Identyfikator

WF 4.15

Wymaga się wsparcie dla procedur i funkcji składowanych w bazie danych. Język programowania musi być językiem proceduralnym, blokowym (umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierającym obsługę wyjątków. W przypadku, gdy wyjątek nie ma zadeklarowanej obsługi wewnątrz bloku, w razie jego wystąpienia wyjątek powinien być automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu.


Identyfikator

WF 4.16

Wymaga się, aby procedury i funkcje składowane miały możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o typach złożonych, definiowanych przez użytkownika. Funkcje muszą mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowe muszą umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury).


Identyfikator

WF 4.17

Wymaga się, aby była możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej).


Identyfikator

WF 4.18

Wymaga się, aby oprogramowanie bazodanowe umożliwiało deklarowanie wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy musi umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views).


Identyfikator

WF 4.19

Wymaga się, aby w przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił ww. błąd lub wyjątek.


Identyfikator

WF 4.20

Wymaga się, aby istniała możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych.


Identyfikator

WF 4.21

Wymaga się, aby oprogramowanie bazodanowe umożliwiało wymuszanie złożoności hasła użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku przekroczenia limitu nieudanych logowań.


Identyfikator

WF 4.22

Wymaga się, aby przywileje użytkowników bazy danych były określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu/modyfikacji tabeli, wykonania procedury). Oprogramowanie bazodanowe musi umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.


Identyfikator

WF 4.23

Wymaga się, aby oprogramowanie bazodanowe umożliwiało:

  • wykonywanie i katalogowanie kopii bezpieczeństwa bezpośrednio przez serwer bazy danych;

  • zautomatyzowane usuwanie zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów;

  • integrację z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, OmniBack, ArcServe itd);

  • wykonywanie kopii bezpieczeństwa zarówno w trybie offline oraz w trybie online.


Identyfikator

WF 4.24

Wymaga się, aby oprogramowanie bazodanowe umożliwiało wykonywanie kopii bezpieczeństwa w trybie online (hot backup).


Identyfikator

WF 4.25

Wymaga się, aby odtwarzanie umożliwiało odzyskanie stanu danych z chwili wystąpienia awarii bądź cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili wystąpienia awarii odtwarzaniu może podlegać cała baza danych bądź pojedyncze pliki danych.


Identyfikator

WF 4.26

Wymaga się, aby w przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników.


Identyfikator

WF 4.27

Wymaga się, aby oprogramowanie bazodanowe posiadało wbudowaną obsługę wyrażeń regularnych była zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych.


Identyfikator

WF 4.28

Wymaga się, aby była możliwość budowy klastra na węźle obsługiwanym przez maksymalnie 2 procesory.


Identyfikator

WF 4.29

Wymaga się, aby była możliwość pracy na maszynie wyposażonej maksymalnie w 2 gniazda procesorowe (ang. sockets).


Identyfikator

WF 4.30

Wymaga się, aby była możliwość obsługi do 16 wątków.


Identyfikator

WF 4.31

Wymaga się, aby producent relacyjnej bazy danych dostarczył usługę pozwalająca na tworzenie kopii zapasowej bazy danych w chmurze należącej do producenta.


Projekt: Platforma Elektronicznych Usług Geodezyjnych – PEUG

dofinansowany z Unii Europejskiej w ramach środków Europejskiego Funduszu Rozwoju Regionalnego

w ramach Regionalnego Programu Operacyjnego Województwa Dolnośląskiego na lata 2014-2020,

Oś priorytetowa 2. Technologie informacyjno- komunikacyjne, Działanie 2.1. E-usługi publiczne

Document Metadata

Filed: May 15th, 2018