Dostawa macierzy dyskowej – Warszawa

Zamawiający informuje, że dopuszcza rozwiązanie, gdzie wyliczanie kodów parzystości jest realizowane przez procesor macierzy i usuwa wymaganie wskazane w tabeli w pkt 4.1 wiersz 4 lit. b) Załącznika nr 1 do SWZ – Szczegółowy opis przedmiotu zamówienia. W związku z powyższym Zamawiający dokonuje zmiany treści SWZ - patrz zmiana nr 1.

Zamawiający informuje, że dopuszcza rozwiązanie zapewniające separację danych oraz kontrolę dostępu do zasobów z wykorzystaniem mechanizmów uprawnień i kontroli dostępu dostępnych w macierzy, bez konieczności tworzenia odrębnych tenantów, z zachowaniem możliwości integracji z usługami katalogowymi AD/LDAP i usuwa wymaganie wskazane w tabeli w pkt 4.1 wiersz 10 lit. b) Załącznika nr 1 do SWZ – Szczegółowy opis przedmiotu zamówienia. W związku z powyższym Zamawiający dokonuje zmiany treści SWZ - patrz zmiana nr 1.

Zamawiający wyjaśnia, że dopuszcza zaoferowanie macierzy, w której automatyczna odbudowa danych po awarii dysku realizowana jest z wykorzystaniem rozproszonej przestrzeni zapasowej, automatycznie rezerwowanej przez mechanizmy ochrony danych macierzy, bez konieczności stosowania dedykowanych dysków SPARE, przy zachowaniu wymaganej odporności na awarie i integralności danych co jest wyrażone w tabeli w pkt 4.1 wiersz 3 lit. f) – Dyski i pojemność Załącznika nr 1 do SWZ – SOPZ.

Zamawiający informuje, że dopuszcza zaoferowanie macierz, która zapewnia ochronę danych oraz wysoką dostępność z wykorzystaniem własnego, wewnętrznego mechanizmu organizacji i ochrony danych, bez konieczności udostępniania funkcji dynamicznej migracji pomiędzy poziomami RAID, pod warunkiem zapewnienia wymaganej wydajności, pojemności i odporności na awarie i usuwa wymaganie wskazane w tabeli w pkt 4.1 wiersz 10 lit. i) Załącznika nr 1 do SWZ – Szczegółowy opis przedmiotu zamówienia. W związku z powyższym Zamawiający dokonuje zmiany treści SWZ - patrz zmiana nr 1.

Odpowiedź na pytanie nr 4: Zamawiający informuje, że dopuszcza zaoferowanie macierz, która zapewnia ochronę danych oraz wysoką dostępność z wykorzystaniem własnego, wewnętrznego mechanizmu organizacji i ochrony danych, bez konieczności udostępniania funkcji dynamicznej migracji pomiędzy poziomami RAID, pod warunkiem zapewnienia wymaganej wydajności, pojemności i odporności na awarie i usuwa wymaganie wskazane w tabeli w pkt 4.1 wiersz 10 lit. i) Załącznika nr 1 do SWZ – Szczegółowy opis przedmiotu zamówienia. W związku z powyższym Zamawiający dokonuje zmiany treści SWZ - patrz zmiana nr 1. II. Zamawiający działając na podstawie art. 137 ust. 1 ustawy Pzp dokonuje następującej zmiany treści SWZ: Zmiana nr 1: Dot.: Załącznik nr 1 do SWZ – Szczegółowy opis przedmiotu zamówienia, tabela w pkt 4.1 wiersz 4 lit. b), wiersz 10 lit. b) i i): BYŁO: L.p. Nazwa parametru Wartości wymagane przez Zamawiającego A B C 4 Poziomy RAID a) macierz musi zapewniać wsparcie dla poziomów RAID z wyliczaniem parzystości lub podwójnej parzystości, b) obliczanie sum kontrolnych (kodów parzystości) dla grup dyskowych RAID musi być realizowane w sposób sprzętowy przez dedykowany układ w macierzy. 10 Inne wymagania a) macierz musi pozwalać na kreowanie wielu systemów plików, b) macierz musi obsługiwać wielodostęp poprzez kreowanie tenantów (nie mniej niż 10) z możliwością separacji danych, każdy tenant musi pozwalać na zarządzanie własną pulą użytkowników synchronizowaną z AD/LDAP, c) macierz musi posiadać wsparcie dla wielościeżkowości (ang. multipath) dla systemu Red Hat Enterprise Linux 9, d) macierz musi posiadać możliwość integracji w środowisku Kuberenetes z wykorzystaniem interfejsu CSI (ang. container storage interface) dostarczanego przez producenta macierzy; sterownik CSI musi obsługiwać przynajmniej wersję 1.1 specyfikacji CSI (m.in. pozwalać na zmianę rozmiaru wolumenu) i musi znajdować się na liście sterowników dla Kubernetes1, e) macierz musi umożliwiać dynamiczne rozszerzenie rozmiaru wolumenów logicznych bez przerywania pracy macierzy i bez przerywania dostępu do danych znajdujących się na danym wolumenie, f) macierz musi posiadać funkcjonalność wykonywania migawek (ang. snapshot) minimum 32 per wolumen, g) macierz musi wspierać mechanizm thin-provisioning’u, h) macierz musi wspierać automatyczną odbudowę po awarii z wykorzystaniem dysków SPARE, i) macierz musi pozwalać na dynamiczną migrację pomiędzy poziomami RAID, j) 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, k) macierz musi umożliwiać wysyłanie pełnych logów do zewnętrznego kolektora logów (typu syslog), l) macierz musi obsługiwać replikację synchroniczną/asynchroniczną dla bloków danych oraz dla plików; jeżeli funkcjonalność replikacji wymaga dodatkowych licencji muszą być one dostarczone, m) wszystkie licencje na funkcjonalności…