Przejdź do treści
← Wróć do listy

Dostawa środowiska serwerowego – Elbląg

Przedmiot zamówienia

AI

Dostawa, montaż, konfiguracja i wdrożenie kompletnego środowiska serwerowo-macierzowego dla Urzędu Miejskiego w Elblągu, obejmujące: - 3 serwery typu RACK (węzły klastra wysokiej dostępności), - 2 macierze dyskowe SAN typu all-flash z synchronizacją danych, - 2 przełączniki sieciowe SAN FC (dwie niezależne fabryki), - oprogramowanie wirtualizacyjne z centralną konsolą zarządzania (licencje dla 2 serwerów), - 3 licencje serwerowego systemu operacyjnego, - 1 szafa serwerowa RACK, - komplety okablowania i akcesoriów połączeniowych. W zakres wchodzą także uruchomienie i testy (w tym wydajnościowe i przełączania awaryjnego), przygotowanie dokumentacji powykonawczej oraz przeprowadzenie instruktażu dla administratorów.

Trudność: średnia

Zamówienie wymaga skoordynowanej dostawy i integracji kilku współzależnych elementów infrastruktury (klaster serwerów, macierze z synchronizacją, sieć SAN FC, platforma wirtualizacyjna) wraz z konfiguracją i testami awaryjnymi.

Terminy realizacji

Czas na realizację
60 dni od udzielenia zamówienia
Wymagany okres gwarancji
min. 36 miesięcy (max 60 w kryterium)

Kryteria wyboru oferty

AI

Wagi punktowe, według których zamawiający oceni oferty.

Cena (brutto)
60%
Okres gwarancjimin. 36, maks. 60 mies.
40%

Czerwone flagi

AI

Sygnały, na które warto zwrócić uwagę przed startem.

SWZ zmodyfikowany 9 dni po udostępnieniu dokumentów
Późna modyfikacja specyfikacji może sugerować dostosowanie wymagań pod konkretnego wykonawcę lub celowe utrudnienie konkurencji, która przygotowała ofertę na pierwotną wersję SWZ.

Kary i sankcje

AI
  • Wadium: 3 000 zł (pieniądz / gwarancje bankowe i ubezpieczeniowe / poręczenia PARP)
  • Kary umowne: w projekcie umowy (zał. nr 3)

Pytania i odpowiedzi

16

Wyodrębnione z wyjaśnień treści SWZ.

1Dyski SSD NVMe zamiast SSD SAS Dotyczy: rozdział 2 „Macierze dyskowe SAN – 2 szt.”, tabela: poz. 5,7,13 Czy Zamawiający dopuści zastosowanie dwukanałowych dysków SSD NVMe zamiast SSD SAS, zarówno w obudowie podstawowej, jak i w półkach rozszerzeń, oraz monitorowanie żywotności tych dysków NVMe? Pozostałe wymagania zostaną zachowane, w szczególności: minimum 80 TB pojemności użytecznej na każdą macierz, pojemność pojedynczego dysku nie większa niż 8 TB, zakaz stosowania QLC, brak obsługi HDD oraz możliwość rozbudowy do minimum 80 dysków bez wymiany lub dodawania kontrolerów.
Zamawiający informuje, że dokonał zmiany treści SWZ nr 2 poprzez zmianę zapisu w rozdziale 2 w tabeli pozycja 5, 7 i 13 w WARUNKACH TECHNICZNYCH stanowiących ZAŁĄCZNIK NR 4 do SWZ. Zamawiający ponadto informuje, że dopuszcza zastosowanie dwukanałowych dysków SSD NVMe zamiast SSD SAS, pod warunkiem zachowania wszystkich pozostałych wymagań OPZ, w tym pojemności, trwałości, redundancji i możliwości rozbudowy.
2Interfejsy do podłączania półek NVMe Dotyczy: rozdział 2, tabela: poz. 9,7 Czy Zamawiający dopuści zastosowanie redundantnych interfejsów Ethernet/RoCE do obsługi półek NVMe, realizowanych przez karty rozszerzeń, zamiast wbudowanych portów SAS 12 Gb/s? Czy Zamawiający dopuści również, aby rozbudowa do minimum 80 dysków wymagała dodania odpowiednich kart, przewodów i przełączników do obsługi półek, bez wymiany lub dodawania kontrolerów macierzowych? Wszystkie elementy niezbędne do działania konfiguracji dostarczanej w ramach zamówienia zapewni Wykonawca.
Zamawiający informuje, że dopuszcza redundantne interfejsy Ethernet/RoCE do obsługi półek NVMe oraz rozbudowę o dodatkowe karty, przewody i przełączniki, o ile możliwe będzie osiągnięcie minimum 80 dysków bez wymiany lub dodawania kontrolerów i wszystkie wymagane elementy zostaną dostarczone przez Wykonawcę.
3Dopuszczenie architektury active-active z ALUA Dotyczy: rozdział 2, tabela, poz. 3 „Kontrolery dyskowe”: Czy Zamawiający dopuści macierz z dwoma aktywnymi kontrolerami, w której oba kontrolery jednocześnie obsługują operacje wejścia/wyjścia, natomiast dostęp do poszczególnych LUN-ów wykorzystuje ALUA i rozróżnienie ścieżek zoptymalizowanych oraz niezoptymalizowanych? Oprogramowanie wielościeżkowe hostów będzie automatycznie wybierało właściwe ścieżki, a awaria pojedynczego kontrolera nie będzie wymagała ręcznego przełączenia dostępu do danych.
Zamawiający informuje, że dopuszcza architekturę active-active z mechanizmem ALUA, pod warunkiem jednoczesnej pracy obu kontrolerów, automatycznego przełączania ścieżek oraz zachowania dostępu do danych po awarii pojedynczego kontrolera.
4Dopuszczenie RAID-DP i RAID-TEC Dotyczy: rozdział 2, tabela: poz. 5, 11,4 Czy Zamawiający dopuści macierz obsługującą RAID4, RAID-DP i RAID-TEC zamiast obowiązku obsługi wszystkich wymienionych poziomów; RAID5, RAID6 i RAID10 oraz dystrybuowanej przestrzeni zapasowej? RAID-DP zapewni odporność na jednoczesną awarię dowolnych dwóch dysków w grupie RAID, a RAID-TEC — dowolnych trzech. Zachowana zostanie możliwość definiowania dysków zapasowych zgodnie z poz. 6 tabeli. Czy Zamawiający zaakceptuje jednocześnie: • obliczenie wymaganej pojemności użytecznej minimum 80 TB po zastosowaniu RAID-DP, bez uwzględniania korzyści z deduplikacji i kompresji;
Zamawiający informuje, że nie przychyla się do wniosku Wykonawcy.
5Zmiana zestawu portów Ethernet Dotyczy: rozdział 2, tabela, poz. 9 „Dostępne interfejsy”: Czy Zamawiający dopuści następujący zestaw interfejsów na każdą macierz: • minimum 8 portów FC o przepustowości co najmniej 32 Gb/s, z wkładkami; • minimum 8 portów Ethernet 10/25 Gb/s do transmisji danych, z wkładkami dobranymi do wymaganych połączeń; • minimum 2 dedykowane porty zarządzające Ethernet 1 Gb/s RJ-45, po jednym na kontroler; zamiast wymaganego zestawu portów Ethernet? Czy Zamawiający dopuści odpowiednio wkładki SFP28 lub inne właściwe dla prędkości portów oraz brak wkładek optycznych w portach zarządzających RJ-45?
Zamawiający informuje, że dopuszcza wskazany zestaw portów FC 32 Gb/s, Ethernet 10/25 Gb/s i dedykowanych portów zarządzających 1 Gb/s RJ-45 oraz właściwe wkładki SFP28, pod warunkiem zachowania redundancji i wymaganej możliwości rozbudowy portów hostowych.
6Sposób rozbudowy portów hostowych Dotyczy: rozdział 2, tabela, poz. 9 „Dostępne interfejsy”: Czy Zamawiający dopuści uzyskanie wymaganej dodatkowej liczby portów również przez wymianę zainstalowanych kart na karty o większej liczbie portów lub zmianę ich obsady, zamiast wyłącznie przez dołożenie kart do wolnych slotów? Po rozbudowie zachowana zostanie zaakceptowana przez Zamawiającego bazowa liczba portów hostowych, wymagany przyrost liczby portów oraz redundancja połączeń. Przełączniki służące do obsługi półek dyskowych nie będą traktowane jako dodatkowe porty hostowe macierzy.
Zamawiający informuje, że nie przychyla się do wniosku Wykonawcy.
7Organizacja pamięci RAM i ochrony zapisów Dotyczy: rozdział 2, tabela, poz. 8 „Pamięć Cache”: Czy Zamawiający dopuści architekturę wykorzystującą łącznie minimum 256 GB pamięci RAM kontrolerów, współdzielonej przez funkcje systemowe i buforowanie danych, oraz minimum 32 GB odrębnej, zabezpieczonej pamięci NVRAM/NVMEM do ochrony potwierdzonych operacji zapisu? Rozwiązanie zapewni zachowanie potwierdzonych zapisów po awarii zasilania. Dyski SSD/NVMe ani karty FLASH nie będą wykorzystywane jako rozszerzenie cache odczytu; dopuszczona będzie pamięć nieulotna służąca ochronie zapisów.
Zamawiający informuje, że dopuszcza zastosowanie minimum 256 GB współdzielonej pamięci RAM kontrolerów oraz minimum 32 GB odrębnej pamięci NVRAM/NVMEM do ochrony potwierdzonych zapisów, pod warunkiem spełnienia wymagań wydajnościowych OPZ i zachowania danych po awarii zasilania.
8Poziom włączania deduplikacji i kompresji Dotyczy: rozdział 2, tabela, poz. 15 „Deduplikacja/Kompresja”: Czy Zamawiający dopuści zarządzanie deduplikacją i kompresją na poziomie wolumenu logicznego zawierającego LUN, przy możliwości umieszczenia każdego LUN-u w oddzielnym wolumenie? Takie przypisanie umożliwi niezależne włączanie i wyłączanie redukcji danych dla poszczególnych LUN-ów. Zachowany zostanie wymóg deduplikacji i kompresji w trybie in-line.
Zamawiający informuje, że dopuszcza zarządzanie deduplikacją i kompresją na poziomie wolumenu zawierającego LUN, jeżeli dla każdego LUN-u będzie możliwe niezależne włączanie i wyłączanie tych funkcji w trybie in-line.
9Realizacja klastra wysokiej dostępności Dotyczy: rozdział 2, tabela, poz. 17 „Klaster macierzowy” Czy Zamawiający uzna realizację klastra wysokiej dostępności przez SnapMirror Active Sync, z synchroniczną replikacją IP i niezależnym arbitrem, za dopuszczalny sposób realizacji poz. 17, pod warunkiem zapewnienia wymaganej ciągłości dostępu do chronionych zasobów i automatycznego przełączania po awarii? Prosimy również o wyjaśnienie, czy automatyczny failover z macierzy niepreferowanej na preferowaną oznacza przełączenie po awarii macierzy aktualnie obsługującej zasoby, czy również obowiązkowy automatyczny powrót do pierwotnej macierzy po usunięciu awarii.
Zamawiający informuje, że dopuszcza realizację klastra za pomocą SnapMirror Active Sync z replikacją synchroniczną IP i niezależnym arbitrem, pod warunkiem zapewnienia ciągłości dostępu do danych i automatycznego przełączania po awarii; dopuszcza się kontrolowany powrót do pierwotnej macierzy po usunięciu awarii.
10Warunki realizacji klastra geograficznego Dotyczy: „Pozostałe wymagania i warunki realizacji”, pkt 6; rozdział 2, tabela, poz. 17 „Klaster macierzowy”; rozdział 6 „Szafa serwerowa RACK” oraz wstęp OPZ przewidujący dostawę szafy serwerowej. Prosimy o wskazanie: • lokalizacji obu macierzy i odległości pomiędzy nimi; • dostępnych łączy, ich przepustowości, redundancji i opóźnienia RTT; • dostępnego, niezależnego środowiska dla arbitra; • elementów infrastruktury replikacyjnej, które ma dostarczyć Wykonawca. Jeżeli macierze mają pracować w odrębnych lokalizacjach, prosimy o wyjaśnienie, czy Zamawiający zapewnia szafę i zasilanie w drugiej lokalizacji, czy należy je uwzględnić w dostawie.
Zamawiający informuje, że macierze będą znajdowały się w jednej tej samej lokalizacji, w tym samym pomieszczeniu, w jednej tej samej dostarczonej szafie RACK.
11Historia wydajności Dotyczy: rozdział 2, tabela, poz. 13 „Zarządzanie”: Czy Zamawiający dopuści macierz zapewniającą dostęp do historycznych danych wydajnościowych z okresu co najmniej 12 miesięcy bezpośrednio z wbudowanego interfejsu graficznego, bez konieczności dostarczania dodatkowego serwera fizycznego, maszyny wirtualnej lub zewnętrznego systemu monitorowania, zamiast wymaganej historii obejmującej co najmniej 2 lata? Dopuszczenie takiego rozwiązania umożliwi analizę długoterminowych trendów wydajnościowych przy wykorzystaniu narzędzi wbudowanych w macierz, ograniczając koszty oraz złożoność utrzymania dodatkowej infrastruktury monitorującej.
Zamawiający informuje, że nie przychyla się do wniosku Wykonawcy.
12Mechanizmy równoważne wobec T10 PI Dotyczy: rozdział 2, tabela, poz. 20 „Integralność danych”: Czy Zamawiający dopuści zamiast zgodności ze specyfikacją T10 PI mechanizmy ochrony integralności oparte na sumach kontrolnych i weryfikacji bloków danych? Wykonawca przedstawi dokumentację producenta określającą zakres ochrony, chronione etapy przetwarzania i transferu oraz sposób wykrywania uszkodzeń. Prosimy o określenie, jakie odcinki ścieżki transferu muszą być objęte ochroną, aby rozwiązanie zostało uznane za równoważne.
Zamawiający informuje, że nie przychyla się do wniosku Wykonawcy.
13Klonowanie i synchronizacja danych Dotyczy: rozdział 2, tabela, poz. 14 „Kopie wewnątrz macierzy”: Klonowanie „w ramach macierzy za pomocą wewnętrznych kontrolerów macierzowych” z możliwością „synchronizacji danych z wolumenu źródłowego na docelowy oraz resynchronizacji danych z wolumenu docelowego na źródłowy”. Czy Zamawiający dopuści realizację tych funkcji przez współpracujące mechanizmy klonowania i replikacji wewnątrz tej samej macierzy, zamiast wymagania realizacji wszystkich operacji przez jeden mechanizm klonowania? Zachowana zostanie możliwość synchronizacji oraz resynchronizacji w obu wskazanych kierunkach, z wykorzystaniem kontrolerów macierzy, bez obciążania serwerów kopiowaniem danych.
Zamawiający informuje, że dopuszcza realizację klonowania, synchronizacji i resynchronizacji za pomocą współpracujących mechanizmów macierzy, pod warunkiem zachowania funkcjonalności w obu kierunkach bez angażowania serwerów w kopiowanie danych.

Historia zmian

28.10.2026 — publikacja ogłoszenia
05.11.2026 — aktualizacja ogłoszenia (Termin składania: 06.11.2026 → 10.11.2026)
05.11.2026 — modyfikacja dokumentacji (2 modyfikacje dokumentacji)
06.11.2026 — aktualizacja ogłoszenia (Termin składania: 10.11.2026 → 12.11.2026)
06.11.2026 — wyjaśnienia i modyfikacja dokumentacji (1 dokument z wyjaśnieniami · 2 modyfikacje dokumentacji)