Załącznik nr 2 do SWZ 
Nr postępowania 10/D-84/PIiZ2024/PN/2024/D  
(Pieczątka firmy) ..................................., dnia .........................

Dane Wykonawcy
Nazwa: ...........................................................................................................................................................................................................
.......................................................................................................................................................................................................................
Siedziba: .......................................................................................................................................................................................................
Dane składającego oświadczenie:
Imię i nazwisko: ......................................................................................................................... 
Sposób reprezentacji Wykonawcy: pełnomocnictwo / wpis w rejestrze lub ewidencji*
FORMULARZ TECHNICZNY PRZEDMIOTU ZAMÓWIENIA

TABELA NR I - DOSTAWA PLATFORMY DO ROZBUDOWY CHMURA PRYWATNA – WIRTUALIZACJA OPARTA NA INFRASTRUKTURZE HIPERKONWERGENTNEJ – 1 kpl.
 
Wymagania szczegółowe dla dostawy platformy do rozbudowy chmura prywatna – wirtualizacja oparta na infrastrukturze hiperkonwergentnej – 1 kpl.

A
Wymagania zamawiającego	B
Wskazania wykonawcy	
Charakterystyka i cechy funkcjonalne przedmiotu zamówienia.
Wymagania minimalne 	Ilość zamawiana 	Specyfikacja oferowanego przedmiotu zamówienia 
Parametry oferowanego sprzętu	Ilość
oferowana	
Platforma do rozbudowy chmura prywatna – wirtualizacja oparta na infrastrukturze hiperkonwergentnej 
	1 komplet	1. ………………………………………………………..
(nazwa, typ, producent)	…… komplet	
I.	SYSTEM	I.	SYSTEM	
1.	Rozwiązanie (sprzęt serwerowy x86, wirtualizator, pamięć masowa zdefiniowana programowo, ochrona i zabezpieczenie danych, zintegrowane zarządzanie) musi być dostarczone, zaprojektowane, zintegrowane oraz wspierane przez jednego dostawcę.
2.	Wszystkie komponenty rozwiązania (sprzęt serwerowy x86, wirtualizator, pamięć masowa zdefiniowana programowo, ochrona i zabezpieczenie danych) muszą być zarządzane z jednego miejsca, za pomocą wbudowanego i zintegrowanego narzędzia. 

3.	Rozwiązanie musi być certyfikowane na serwerach co najmniej 3 globalnych producentów serwerów.
4.	Rozwiązanie musi być niezależne od sprzętu (nie może być ograniczone do określonego dostawcy sprzętu x86). Wymagana jest możliwość przenoszenia licencji lub subskrypcji pomiędzy wszystkimi wspieranymi platformami x86.
5.	Platforma sprzętowa w zaproponowanej konfiguracji musi być certyfikowana przez producenta Systemu i znajdować się na publicznie dostępnej liście kompatybilności.
6.	Możliwość wykonywania i monitorowania aktualizacji wszystkich komponentów rozwiązania za pomocą pojedynczego narzędzia zarządzania. Narzędzie musi wykonywać automatyczną weryfikację kompatybilności wersji oprogramowania oraz firmware.

7.	Rozwiązanie musi być samo naprawialne. Oznacza to, że musi utrzymywać określony poziom odporności na awarie oraz stałą wydajność w przypadku awarii, bez konieczności interwencji administratora. Musi także przywrócić odporność tak szybko jak tylko możliwe.
8.	Rozwiązanie musi być niezależne od sieci, nie może wymagać określonego sprzętu sieciowego.
9.	Rozwiązanie musi zapewniać wbudowaną funkcję udostępniania usług pamięci masowej dla maszyn wirtualnych, kontenerów oraz zewnętrznych serwerów fizycznych jako:
1)	blokowe zasoby iSCSI;
2)	plikowe zasoby – poprzez protokoły NFS i SMB;
3)	zasoby obiektowe – kompatybilne z Amazon S3.
Zamawiający wymaga aby dostarczona licencja posiadała funkcjonalność udostępniania zasobów blokowych iSCSI do maszyn wirtualnych działających na platformie chmury prywatnej oraz systemów zewnętrznych. 
10.	Rozwiązanie musi umożliwiać uruchamianie klastrów Kubernetes za pomocą kreatora (tzw. wizard), spełniając następujące kryteria:
1)	musi umożliwiać udostępnienie usług pamięci masowej dla klastra Kubernetes;
2)	pamięć masowa musi obsługiwać plugin CSI (Container Storage Interface);
3)	musi zapewnić wbudowane zarządzanie i orchiestrację kontenerów;
4)	rozwiązanie musi być kompatybilne z Google Kubernetes framework.
11.	Rozwiązanie musi wspierać różne warstwy pamięci masowej:
1)	SSD i NVMe jako warstwa wydajnościowa;
2)	NL-SAS/SATA/SSD jako warstwa pojemnościowa.
12.	Rozwiązanie musi zapewniać zautomatyzowane, działające w czasie rzeczywistym, wielowarstwowe składowanie danych (ang. tiering) pomiędzy nośnikami SSD/NVMe (warstwa buforująca i wydajnościowa) oraz HDD/SSD (warstwa pojemnościowa), w celu zapewnienia optymalnej wydajności. 
Jeśli wielowarstwowe składowanie (ang. tiering) nie jest dostępne, wówczas rozwiązanie musi być w całości zbudowane w oparciu o dyski  NVMe DWPD 3 a także musi zostać dostarczona gwarancja ceny nośnika SSD/NVMe w całym okresie trwania kontraktu.
W przypadku rozwiązania opartego o technologię cache’owania danych, wymagany współczynnik warstwy wydajnościowej do warstwy pojemnościowej to 30%. 
W przypadku rozwiązania opartego o technologie cache’owania danych, zamawiający wymaga odpowiedniej wydajności oraz w wydajności minimum 140 000 zapisów/sec oraz wytrzymałości na poziomie 20 000 TBW.
13.	Jeśli system plików w wyniku założeń projektowych architektury lub jako najlepsza praktyka nie powinien być całkowicie zapełniany przez dane użytkownika, wówczas niezbędna wolna przestrzeń (ang. slack space) powinna zostać uwzględniona dodatkowo i doliczona do pojemności surowej węzła.
14.	Rozwiązanie musi umożliwiać utworzenie kontenera danych bez współczynnika odporności tzw. RAID 0 lub Resiliance Factor 1, który będzie przeznaczony dla aplikacji i baz danych posiadające wewnętrzne mechanizmy replikacji danych.  
15.	Wszystkie węzły muszą być hiperkonwergentne, a lokalne (wewnętrzne) dyski wszystkich węzłów muszą stanowić klaster prezentowany jako pojedyncza i rozproszona pula zasobów dostępna dla wszystkich węzłów kontrolowanych przez wirtualizator. Węzły obliczeniowe nie są akceptowane.
16.	Rozwiązanie musi umożliwiać dodawanie serwerów typu Storage Node, które powiększają sumaryczną pojemność klastra, lecz nie umożliwiają uruchomiania maszyn wirtualnych na tych serwerach. 

17.	Rozwiązanie musi zapewniać usługę kompresji danych, w trybie inline oraz post-process, w ramach dostarczonej licencji. 
Wymaganie dotyczy zarówno konfiguracji hybrydowych, jak i All-Flash czy NVMe.
18.	Rozwiązanie musi posiadać funkcjonalność usuwania wielu nodów w klastra.  
19.	Poniższe usługi i parametry pamięci masowej muszą być konfigurowalne osobno dla każdej maszyny wirtualnej lub kontenera danych oraz muszą być zawarte w dostarczonej licencji:
1)	Kompresja;
2)	Deduplikacja; 
3)	Erasure Coding.
20.	Rozwiązanie musi zapewniać funkcję tworzenia kopii migawkowych oraz klonów maszyn wirtualnych, także z zapewnieniem spójności z punktu widzenia aplikacji (co najmniej dla systemów operacyjnych Windows oraz Linux) . Funkcja ta musi być wbudowana w platformę i realizowana na poziomie pamięci masowej.
21.	W przypadku awarii pojedynczego serwera lub dysku, centralna konsola zarządzania system  musi wskazywać przewidywany czas potrzeby do odbudowany danych. 
22.	Platforma musi zapewniać bliskość danych względem miejsca ich przetwarzania (ang. data locality). Oznacza to, że zastosowana architektura i wykorzystywane algorytmy rozkładania danych pomiędzy węzły platformy, muszą nieustannie zmierzać do umieszczenia danych należących do maszyny wirtualnej na lokalnych zasobach pamięci masowej węzła, na którym uruchomiona jest dana maszyna wirtualna.
23.	System musi posiadać mechanizmy Quality of service umożliwiające przypisanie maksymalnej ilości IOPS jaką może wykorzystać maszyna wirtualna. 
24.	System musi umożliwiać przypisanie maszyny wirtualnej do szybszej przestrzeni dyskowej np. do NVME gdzie przestrzenią wolniejszą są dyski HDD lub SSD.
25.	Rozwiązanie musi posiadać mechanizmy szyfrowania za pomocą wbudowanych mechanizmów oraz musi wspierać dyski typu SED.

26.	Rozwiązanie musi posiadać natywny menadżer kluczy ( KMS ) w ramach dostarczonego oprogramowania.
27.	Rozwiązanie musi posiadać mechanizmy gwarancji zasobów w przypadku awarii jednego z serwerów w ramach dostarczonego oprogramowania.
28.	Rozwiązanie musi posiadać polityki Affinity.
29.	Rozwiązanie musi posiadać mechanizmy mikrosgemnetacji dla maszyn działających na platformie chmury prywatnej. 
30.	Rozwiązanie musi posiadać mechanizm dokładnej analizy bezpieczeństwa wykorzystując algorytm uczenia maszynowego do uczenia się, raportowania oraz oznaczenia anomalii w oparciu o podstawowe operacje użytkowników czy też logi sieciowe. 	1.	Rozwiązanie (sprzęt serwerowy x86, wirtualizator, pamięć masowa zdefiniowana programowo, ochrona i zabezpieczenie danych, zintegrowane zarządzanie) musi być dostarczone, zaprojektowane, zintegrowane oraz wspierane przez jednego dostawcę. TAK* / NIE*  
2.	Wszystkie komponenty rozwiązania (sprzęt serwerowy x86, wirtualizator, pamięć masowa zdefiniowana programowo, ochrona i zabezpieczenie danych) muszą być zarządzane z jednego miejsca, za pomocą wbudowanego i zintegrowanego narzędzia. TAK* / NIE*  

3.	Rozwiązanie musi być certyfikowane na serwerach co najmniej 3 globalnych producentów serwerów.  TAK* / NIE*  
4.	Rozwiązanie musi być niezależne od sprzętu (nie może być ograniczone do określonego dostawcy sprzętu x86). Wymagana jest możliwość przenoszenia licencji lub subskrypcji pomiędzy wszystkimi wspieranymi platformami x86.  TAK* / NIE*  
5.	Platforma sprzętowa w zaproponowanej konfiguracji musi być certyfikowana przez producenta Systemu i znajdować się na publicznie dostępnej liście kompatybilności.  TAK* / NIE*  
6.	Możliwość wykonywania i monitorowania aktualizacji wszystkich komponentów rozwiązania za pomocą pojedynczego narzędzia zarządzania. Narzędzie musi wykonywać automatyczną weryfikację kompatybilności wersji oprogramowania oraz firmware.  TAK* / NIE*  
7.	Rozwiązanie musi być samo naprawialne. Oznacza to, że musi utrzymywać określony poziom odporności na awarie oraz stałą wydajność w przypadku awarii, bez konieczności interwencji administratora. Musi także przywrócić odporność tak szybko jak tylko możliwe.  TAK* / NIE*  
8.	Rozwiązanie musi być niezależne od sieci, nie może wymagać określonego sprzętu sieciowego.  TAK* / NIE*  
9.	Rozwiązanie musi zapewniać wbudowaną funkcję udostępniania usług pamięci masowej dla maszyn wirtualnych, kontenerów oraz zewnętrznych serwerów fizycznych jako:
1)	blokowe zasoby iSCSI;  TAK* / NIE*  
2)	plikowe zasoby – poprzez protokoły NFS i SMB;  TAK* / NIE*  
3)	zasoby obiektowe – kompatybilne z Amazon S3.  TAK* / NIE*  
Zamawiający wymaga aby dostarczona licencja posiadała funkcjonalność udostępniania zasobów blokowych iSCSI do maszyn wirtualnych działających na platformie chmury prywatnej oraz systemów zewnętrznych.   TAK* / NIE*  
10.	Rozwiązanie musi umożliwiać uruchamianie klastrów Kubernetes za pomocą kreatora (tzw. wizard), spełniając następujące kryteria:
1)	musi umożliwiać udostępnienie usług pamięci masowej dla klastra Kubernetes;  TAK* / NIE*  
2)	pamięć masowa musi obsługiwać plugin CSI (Container Storage Interface);  TAK* / NIE*  
3)	musi zapewnić wbudowane zarządzanie i orchiestrację kontenerów;  TAK* / NIE*  
4)	rozwiązanie musi być kompatybilne z Google Kubernetes framework.  TAK* / NIE*  
11.	Rozwiązanie musi wspierać różne warstwy pamięci masowej:
1)	SSD i NVMe jako warstwa wydajnościowa;  TAK* / NIE*  
2)	NL-SAS/SATA/SSD jako warstwa pojemnościowa.  TAK* / NIE*  
12.	Rozwiązanie musi zapewniać zautomatyzowane, działające w czasie rzeczywistym, wielowarstwowe składowanie danych (ang. tiering) pomiędzy nośnikami SSD/NVMe (warstwa buforująca i wydajnościowa) oraz HDD/SSD (warstwa pojemnościowa), w celu zapewnienia optymalnej wydajności.  TAK* / NIE*  
Jeśli wielowarstwowe składowanie (ang. tiering) nie jest dostępne, wówczas rozwiązanie musi być w całości zbudowane w oparciu o dyski  NVMe DWPD 3 a także musi zostać dostarczona gwarancja ceny nośnika SSD/NVMe w całym okresie trwania kontraktu.
W przypadku rozwiązania opartego o technologię cache’owania danych, wymagany współczynnik warstwy wydajnościowej do warstwy pojemnościowej to 30%.  TAK* / NIE*  
W przypadku rozwiązania opartego o technologie cache’owania danych, zamawiający wymaga odpowiedniej wydajności oraz w wydajności minimum 140 000 zapisów/sec oraz wytrzymałości na poziomie 20 000 TBW.  TAK* / NIE*  
13.	Jeśli system plików w wyniku założeń projektowych architektury lub jako najlepsza praktyka nie powinien być całkowicie zapełniany przez dane użytkownika, wówczas niezbędna wolna przestrzeń (ang. slack space) powinna zostać uwzględniona dodatkowo i doliczona do pojemności surowej węzła.  TAK* / NIE*  
14.	Rozwiązanie musi umożliwiać utworzenie kontenera danych bez współczynnika odporności tzw. RAID 0 lub Resiliance Factor 1, który będzie przeznaczony dla aplikacji i baz danych posiadające wewnętrzne mechanizmy replikacji danych.    TAK* / NIE*  
15.	Wszystkie węzły muszą być hiperkonwergentne, a lokalne (wewnętrzne) dyski wszystkich węzłów muszą stanowić klaster prezentowany jako pojedyncza i rozproszona pula zasobów dostępna dla wszystkich węzłów kontrolowanych przez wirtualizator. Węzły obliczeniowe nie są akceptowane.  TAK* / NIE*  
16.	Rozwiązanie musi umożliwiać dodawanie serwerów typu Storage Node, które powiększają sumaryczną pojemność klastra, lecz nie umożliwiają uruchomiania maszyn wirtualnych na tych serwerach.  TAK* / NIE*  
17.	Rozwiązanie musi zapewniać usługę kompresji danych, w trybie inline oraz post-process, w ramach dostarczonej licencji. Wymaganie dotyczy zarówno konfiguracji hybrydowych, jak i All-Flash czy NVMe.  TAK* / NIE*  
18.	Rozwiązanie musi posiadać funkcjonalność usuwania wielu nodów w klastra.   TAK* / NIE*  
19.	Poniższe usługi i parametry pamięci masowej muszą być konfigurowalne osobno dla każdej maszyny wirtualnej lub kontenera danych oraz muszą być zawarte w dostarczonej licencji:
1)	Kompresja;  TAK* / NIE*  
2)	Deduplikacja;  TAK* / NIE*  
3)	Erasure Coding.  TAK* / NIE*  
20.	Rozwiązanie musi zapewniać funkcję tworzenia kopii migawkowych oraz klonów maszyn wirtualnych, także z zapewnieniem spójności z punktu widzenia aplikacji (co najmniej dla systemów operacyjnych Windows oraz Linux) . Funkcja ta musi być wbudowana w platformę i realizowana na poziomie pamięci masowej.  TAK* / NIE*  
21.	W przypadku awarii pojedynczego serwera lub dysku, centralna konsola zarządzania system  musi wskazywać przewidywany czas potrzeby do odbudowany danych.   TAK* / NIE*  
22.	Platforma musi zapewniać bliskość danych względem miejsca ich przetwarzania (ang. data locality). Oznacza to, że zastosowana architektura i wykorzystywane algorytmy rozkładania danych pomiędzy węzły platformy, muszą nieustannie zmierzać do umieszczenia danych należących do maszyny wirtualnej na lokalnych zasobach pamięci masowej węzła, na którym uruchomiona jest dana maszyna wirtualna.  TAK* / NIE*  
23.	System musi posiadać mechanizmy Quality of service umożliwiające przypisanie maksymalnej ilości IOPS jaką może wykorzystać maszyna wirtualna.  TAK* / NIE*  
24.	System musi umożliwiać przypisanie maszyny wirtualnej do szybszej przestrzeni dyskowej np. do NVME gdzie przestrzenią wolniejszą są dyski HDD lub SSD.  TAK* / NIE*  
25.	Rozwiązanie musi posiadać mechanizmy szyfrowania za pomocą wbudowanych mechanizmów oraz musi wspierać dyski typu SED.  TAK* / NIE*  
26.	Rozwiązanie musi posiadać natywny menadżer kluczy ( KMS ) w ramach dostarczonego oprogramowania.  TAK* / NIE*  
27.	Rozwiązanie musi posiadać mechanizmy gwarancji zasobów w przypadku awarii jednego z serwerów w ramach dostarczonego oprogramowania.  TAK* / NIE*  
28.	Rozwiązanie musi posiadać polityki Affinity.  TAK* / NIE*  
29.	Rozwiązanie musi posiadać mechanizmy mikrosgemnetacji dla maszyn działających na platformie chmury prywatnej.  TAK* / NIE*  
30.	Rozwiązanie musi posiadać mechanizm dokładnej analizy bezpieczeństwa wykorzystując algorytm uczenia maszynowego do uczenia się, raportowania oraz oznaczenia anomalii w oparciu o podstawowe operacje użytkowników czy też logi sieciowe. TAK* / NIE*  	
II.	BEZPIECZEŃSTWO	II.	BEZPIECZEŃSTWO	
1.	System musi wspierać dyski SED.
2.	System musi wspierać dwuskładnikowe uwierzytelnienie do 
     Systemu. 
3.	System musi posiadać tzw. STIG, regularnie aktualizowane i udostępniane przez producenta.
4.	System musi posiadać mechanizm automatycznego wykrywania odchyleń od STIG i automatycznie je naprawiać, zarówno w warstwie wirtualizacji jak i storage. 	1.	System musi wspierać dyski SED.  TAK* / NIE*  
2.	System musi wspierać dwuskładnikowe uwierzytelnienie do Systemu.  TAK* / NIE*  
3.	System musi posiadać tzw. STIG, regularnie aktualizowane i udostępniane przez producenta.  TAK* / NIE*  
4.	System musi posiadać mechanizm automatycznego wykrywania odchyleń od STIG i automatycznie je naprawiać, zarówno w warstwie wirtualizacji jak i storage.  TAK* / NIE*  	
III.	ODPORNOŚĆ NA AWARIĘ, WYSOKA DOSTĘPNOŚĆ, BACKUP, DISASTER RECOVERY	III.	ODPORNOŚĆ NA AWARIĘ, WYSOKA DOSTĘPNOŚĆ, BACKUP, DISASTER RECOVERY	
1.	System musi być odporny na awarię dysku lub serwera, dowolnych komponentów Systemu, nie powodując przerwy w pracy Systemu.

2.	System musi umożliwiać replikację maszyn wirtualnych między ośrodkami w asynchronicznym RPO=1 godzina.  
3.	System musi umożliwiać replikację maszyn wirtualnych między ośrodkami w scenariuszu wiele do wielu dla co najmniej trzech ośrodków. Zamawiający wymaga, aby oprogramowanie posiadało taką funkcjonalność oraz licencje. 
4.	System musi umożliwiać konfigurację polityki replikacji per maszyna wirtualna.
5.	System musi posiadać narzędzie do Disaster Recovery:
1)	Z możliwością określenia kolejności w jakiej maszyny mają zostać uruchomione w drugim ośrodku;
2)	Z mapowaniem adresacji IP per maszyna wirtualna, pomiędzy ośrodkami;
3)	Z funkcją testowania scenariuszy DR, tzw. failover oraz failback.

Zamawiający wymaga aby oprogramowanie posiadało taką funkcjonalność lecz nie jest wymagane dostarczenie licencji.

6.	System musi wspierać odtwarzanie pojedynczych plików ze Snapshotów.
7.	System musi umożliwiać replikację oraz scenariusze Disaster Recover dla różnych hypervisorów w dwóch ośrodkach. 	1.	System musi być odporny na awarię dysku lub serwera, dowolnych komponentów Systemu, nie powodując przerwy w pracy Systemu.  TAK* / NIE*  
2.	System musi umożliwiać replikację maszyn wirtualnych między ośrodkami w asynchronicznym RPO=1 godzina.   TAK* / NIE*  
3.	System musi umożliwiać replikację maszyn wirtualnych między ośrodkami w scenariuszu wiele do wielu dla co najmniej trzech ośrodków. Zamawiający wymaga, aby oprogramowanie posiadało taką funkcjonalność oraz licencje.  TAK* / NIE*  
4.	System musi umożliwiać konfigurację polityki replikacji per maszyna wirtualna.  TAK* / NIE*  
5.	System musi posiadać narzędzie do Disaster Recovery:
1)	Z możliwością określenia kolejności w jakiej maszyny mają zostać uruchomione w drugim ośrodku;  TAK* / NIE*  
2)	Z mapowaniem adresacji IP per maszyna wirtualna, pomiędzy ośrodkami;  TAK* / NIE*  
3)	Z funkcją testowania scenariuszy DR, tzw. failover oraz failback.  TAK* / NIE*  
Zamawiający wymaga aby oprogramowanie posiadało taką funkcjonalność lecz nie jest wymagane dostarczenie licencji.  TAK* / NIE*  
6.	System musi wspierać odtwarzanie pojedynczych plików ze Snapshotów.  TAK* / NIE*  
7.	System musi umożliwiać replikację oraz scenariusze Disaster Recover dla różnych hypervisorów w dwóch ośrodkach.  TAK* / NIE*  	
IV.	USŁUGI PLIKOWE – ZAMAWIAJĄCY WYMAGA ABY OPROGRAMOWANIE POSIADAŁO TAKA FUNKCJONALNOŚĆ LECZ NIE JEST WYMAGANE DOSTARCZENIE LICENCJI. 	IV.	USŁUGI PLIKOWE – ZAMAWIAJĄCY WYMAGA ABY OPROGRAMOWANIE POSIADAŁO TAKA FUNKCJONALNOŚĆ LECZ NIE JEST WYMAGANE DOSTARCZENIE LICENCJI.	
1.	System musi posiadać wbudowane, rozproszone usługi plikowe.

2.	System musi zapewniać usługi plikowe poprzez protokół NFS v3, NFS4, NFS 4.2   oraz SMB.
3.	System musi umożliwiać jednoczesny dostęp do plików za pomocą NFS oraz SMB.
4.	System musi umożliwiać rozbudowę usług plikowych w modelu scale-out, poprzez dokładanie kolejnych węzłów.  
Dodatkowe węzły muszą zwiększać zarówno pojemność usług plikowych jak i ich wydajność.
5.	System usług plikowych musi integrować się z Active Directory oraz rozwiązaniami Antywirus za pomocą protokołu ICAP.
6.	System usług plikowych musi wspierać CFT (Change File Tracking).

7.	System jako opcja musi obsługiwać szyfrowanie danych dla zasobów plikowych (tzw. data at rest encryption). Zamawiający wymaga aby oprogramowanie posiadało możliwość rozbudowy o takie licencje. 
	1.	System musi posiadać wbudowane, rozproszone usługi plikowe.  TAK* / NIE*  
2.	System musi zapewniać usługi plikowe poprzez protokół NFS v3, NFS4, NFS 4.2   oraz SMB.  TAK* / NIE*  
3.	System musi umożliwiać jednoczesny dostęp do plików za pomocą NFS oraz SMB.  TAK* / NIE*  
4.	System musi umożliwiać rozbudowę usług plikowych w modelu scale-out, poprzez dokładanie kolejnych węzłów.  TAK* / NIE*  
    Dodatkowe węzły muszą zwiększać zarówno pojemność usług plikowych jak i ich wydajność.  TAK* / NIE*  
5.	System usług plikowych musi integrować się z Active Directory oraz rozwiązaniami Antywirus za pomocą protokołu ICAP.  TAK* / NIE*  
6.	System usług plikowych musi wspierać CFT (Change File Tracking).  TAK* / NIE*  
7.	System jako opcja musi obsługiwać szyfrowanie danych dla zasobów plikowych (tzw. data at rest encryption). Zamawiający wymaga aby oprogramowanie posiadało możliwość rozbudowy o takie licencje.  TAK* / NIE*  	
V.	USŁUGI OBIEKTOWE ZAMAWIAJĄCY WYMAGA ABY OPROGRAMOWANIE POSIADAŁO TAKĄ FUNKCJONALNOŚĆ LECZ NIE JEST WYMAGANE DOSTARCZENIE LICENCJI 	V.	USŁUGI OBIEKTOWE ZAMAWIAJĄCY WYMAGA ABY OPROGRAMOWANIE POSIADAŁO TAKĄ FUNKCJONALNOŚĆ LECZ NIE JEST WYMAGANE DOSTARCZENIE LICENCJI	
1.	System musi posiadać wbudowane, rozproszone usługi obiektowe.

2.	System musi zapewniać usługi obiektowe poprzez protokół S3.

3.	System musi umożliwiać rozbudowę usług obiektowych w modelu scale-out, poprzez dokładanie kolejnych węzłów. Dodatkowe węzły muszą zwiększać zarówno pojemność usług plikowych jak i ich wydajność.
4.	System musi posiadać możliwość replikacji zasobów plikowych pomiędzy klastrami z RPO = 1 minuta.
5.	System usług obiektowych musi integrować się z Active Directory.

6.	System usług obiektowych musi zapewniać WORM (Write Once Read Many) oraz wersjonowanie obiektów.
7.	System musi obsługiwać szyfrowanie danych dla zasobów plikowych (tzw. data at rest encryption).
8.	System musi obsługiwać REST API.
9.	Jeżeli System nie posiada wbudowanych usług obiektowych, wymagane jest dostarczenie oddzielnego rozwiązania usług obiektowych w modelu scale-out, o liczbie węzłów i pojemności zgodnych z wymaganiami Systemu, spełniającego wszystkie pozostałe zapisy powyżej. 	1.	System musi posiadać wbudowane, rozproszone usługi obiektowe.  TAK* / NIE*  
2.	System musi zapewniać usługi obiektowe poprzez protokół S3.  TAK* / NIE*  
3.	System musi umożliwiać rozbudowę usług obiektowych w modelu scale-out, poprzez dokładanie kolejnych węzłów. Dodatkowe węzły muszą zwiększać zarówno pojemność usług plikowych jak i ich wydajność.  TAK* / NIE*  
4.	System musi posiadać możliwość replikacji zasobów plikowych pomiędzy klastrami z RPO = 1 minuta.  TAK* / NIE*  
5.	System usług obiektowych musi integrować się z Active Directory.  TAK* / NIE*  
6.	System usług obiektowych musi zapewniać WORM (Write Once Read Many) oraz wersjonowanie obiektów.  TAK* / NIE*  

7.	System musi obsługiwać szyfrowanie danych dla zasobów plikowych (tzw. data at rest encryption).  TAK* / NIE*  
8.	System musi obsługiwać REST API.  TAK* / NIE*  
9.	Jeżeli System nie posiada wbudowanych usług obiektowych, wymagane jest dostarczenie oddzielnego rozwiązania usług obiektowych w modelu scale-out, o liczbie węzłów i pojemności zgodnych z wymaganiami Systemu, spełniającego wszystkie pozostałe zapisy powyżej.  TAK* / NIE*  	
VI.	ZARZĄDZANIE 	VI.	ZARZĄDZANIE  	
1.	Zarządzanie Systemem musi odbywać się z pojedynczej konsoli.

2.	System musi umożliwiać bezprzerwową rozbudowę klastra, poprzez dołożenie kolejnych węzłów. System musi automatycznie rozłożyć równomiernie dane w klastrze, bez ingerencji administratora.

3.	Konsola zarządzania Systemem musi umożliwiać podnoszenie wersji Systemu (sterowniki serwerów, hypervisor, podsystem storage) bez przerwy w pracy Systemu dla dostarczonego rozwiązania serwerowego. 
4.	System musi automatycznie sprawdzać kompatybilność podnoszonych elementów Systemu (sterowniki serwerów, hypervisor, podsystem storage) eliminując możliwość omyłkowego podniesienia jednego z komponentów do niewłaściwej wersji.

5.	System musi prognozować wzrost pojemności Systemu na podstawie danych historycznych wraz ze scenariuszami „co jeśli”.

6.	System musi udostępniać szczegółowe informacje na temat maszyn wirtualnych:
1)	Wydajność maszyn wirtualnych (utylizacja CPU/RAM/IOPS oraz opóźnienie/latency);
2)	Rekomendacje w temacie przypisanych zasobów (za mało / za dużo CPU lub RAM).
7.	System musi wspierać REST API dla całej platformy. 
8.	 System musi posiadać wbudowany Self Service Portal, z możliwością wydzielania zasobów CPU/RAM/storage dla konkretnych użytkowników bądź grup użytkowników, uwierzytelnionych przez Active Directory.	1.	Zarządzanie Systemem musi odbywać się z pojedynczej konsoli.  TAK* / NIE*  
2.	System musi umożliwiać bezprzerwową rozbudowę klastra, poprzez dołożenie kolejnych węzłów. System musi automatycznie rozłożyć równomiernie dane w klastrze, bez ingerencji administratora.  TAK* / NIE*  
3.	Konsola zarządzania Systemem musi umożliwiać podnoszenie wersji Systemu (sterowniki serwerów, hypervisor, podsystem storage) bez przerwy w pracy Systemu dla dostarczonego rozwiązania serwerowego.  TAK* / NIE*  
4.	System musi automatycznie sprawdzać kompatybilność podnoszonych elementów Systemu (sterowniki serwerów, hypervisor, podsystem storage) eliminując możliwość omyłkowego podniesienia jednego z komponentów do niewłaściwej wersji.  TAK* / NIE*  
5.	System musi prognozować wzrost pojemności Systemu na podstawie danych historycznych wraz ze scenariuszami „co jeśli”.  TAK* / NIE*  
6.	System musi udostępniać szczegółowe informacje na temat maszyn wirtualnych:
1)	Wydajność maszyn wirtualnych (utylizacja CPU/RAM/IOPS oraz opóźnienie/latency);  TAK* / NIE*  
2)	Rekomendacje w temacie przypisanych zasobów (za mało / za dużo CPU lub RAM).  TAK* / NIE*  
7.	System musi wspierać REST API dla całej platformy.  TAK* / NIE*  
8.	System musi posiadać wbudowany Self Service Portal, z możliwością wydzielania zasobów CPU/RAM/storage dla konkretnych użytkowników bądź grup użytkowników, uwierzytelnionych przez Active Directory.  TAK* / NIE*  	
VII.	HYPERVISOR 	VII.	HYPERVISOR	
1.	Do zaproponowanego systemu należy dostarczyć licencje na oprogramowanie wirtualizacyjne na każdy dostarczony serwer.

2.	Oprogramowanie wirtualizacyjne musi zapewniać mechanizmy przenoszenia maszyn wirtualnych bezprzerwowo pomiędzy węzłami w klastrze. 
3.	Oprogramowanie wirtualizacyjne musi zapewniać mechanizmy HA w obrębię pojedynczego klastra. 
4.	Oprogramowanie wirtualizacyjne musi posiadać mechanizm inteligentnego umiejscowienia nowych maszyn wirtualnych na serwerach o najmniejszym obciążeniu.
5.	Oprogramowanie wirtualizacyjne musi posiadać mechanizm Affinity Rules.
6.	Oprogramowanie wirtualizacyjne musi umożliwiać tworzenie i zarządzanie wirtualnymi sieciami.
7.	Oprogramowanie wirtualizacyjne musi automatycznie przenosić bezprzerwowo maszyny wirtualne pomiędzy węzłami w klastrze w zależności od ich obciążenia. 
8.	Oprogramowanie wirtualizacyjne musi być w pełni zintegrowane z dostarczoną platformą chmury prywatnej i posiadać wspólną konsole zarządzania. 
9.	Oprogramowanie wirtualizacyjne musi posiadać mechanizmy klonowania maszyn wirtualnych. Klonowanie maszyn wirtualnych musi integrować się z podsystem dyskowym w celu szybkiego wykonywania klonów.
10.	Oprogramowanie wirtualizacyjne musi posiadać wirtualny przełącznik sieciowy, umożliwiający konfigurację ustawień sieci per klaster.
11.	Oprogramowanie musi umożliwiać udostępnienie karty graficznej bezpośrednio do maszyny wirtualnej – technologia GPU Passthrouth.
12.	Oprogramowanie musi umożliwiać podzielenie logiczne podzielenie karty graficznej i przydzielenie jej zasobów do maszyn wirtualnych vGPU. 
13.	Oprogramowanie wirtualizacyjne musi wspierać UEFI dla maszyn wirtualnych. 
14.	Oprogramowanie musi posiadać funkcjonalność typu HA Guaranteed Failover która zabezpiecza zasoby serwerowe, które zostaną zwolnione i udostępnione dla system w przypadku awaria serwera w celu zapewnienia popranej pracy maszyn wirtualnych. Mechanizm musi zapobiegać sytuacji ze po awarii serwera system nie posiada zasobów do uruchomienia maszyn wirtualnych. 	1.	Do zaproponowanego systemu należy dostarczyć licencje na oprogramowanie wirtualizacyjne na każdy dostarczony serwer.  TAK* / NIE*  
2.	Oprogramowanie wirtualizacyjne musi zapewniać mechanizmy przenoszenia maszyn wirtualnych bezprzerwowo pomiędzy węzłami w klastrze.  TAK* / NIE*  
3.	Oprogramowanie wirtualizacyjne musi zapewniać mechanizmy HA w obrębię pojedynczego klastra.  TAK* / NIE*  
4.	Oprogramowanie wirtualizacyjne musi posiadać mechanizm inteligentnego umiejscowienia nowych maszyn wirtualnych na serwerach o najmniejszym obciążeniu.  TAK* / NIE*  
5.	Oprogramowanie wirtualizacyjne musi posiadać mechanizm Affinity Rules.  TAK* / NIE*  
6.	Oprogramowanie wirtualizacyjne musi umożliwiać tworzenie i zarządzanie wirtualnymi sieciami.  TAK* / NIE*  
7.	Oprogramowanie wirtualizacyjne musi automatycznie przenosić bezprzerwowo maszyny wirtualne pomiędzy węzłami w klastrze w zależności od ich obciążenia.   TAK* / NIE*  
8.	Oprogramowanie wirtualizacyjne musi być w pełni zintegrowane z dostarczoną platformą chmury prywatnej i posiadać wspólną konsole zarządzania.  TAK* / NIE*  
9.	Oprogramowanie wirtualizacyjne musi posiadać mechanizmy klonowania maszyn wirtualnych. Klonowanie maszyn wirtualnych musi integrować się z podsystem dyskowym w celu szybkiego wykonywania klonów.  TAK* / NIE*  
10.	Oprogramowanie wirtualizacyjne musi posiadać wirtualny przełącznik sieciowy, umożliwiający konfigurację ustawień sieci per klaster.  TAK* / NIE*  
11.	Oprogramowanie musi umożliwiać udostępnienie karty graficznej bezpośrednio do maszyny wirtualnej – technologia GPU Passthrouth.  TAK* / NIE*  
12.	Oprogramowanie musi umożliwiać podzielenie logiczne podzielenie karty graficznej i przydzielenie jej zasobów do maszyn wirtualnych vGPU.   TAK* / NIE*  
13.	Oprogramowanie wirtualizacyjne musi wspierać UEFI dla maszyn wirtualnych.  TAK* / NIE*  
14.	Oprogramowanie musi posiadać funkcjonalność typu HA Guaranteed Failover która zabezpiecza zasoby serwerowe, które zostaną zwolnione i udostępnione dla system w przypadku awaria serwera w celu zapewnienia popranej pracy maszyn wirtualnych. Mechanizm musi zapobiegać sytuacji ze po awarii serwera system nie posiada zasobów do uruchomienia maszyn wirtualnych. TAK* / NIE*  	
VIII.	PODSYSTEM SERWEROWY DLA MASZYN WIRTUALNYCH	VIII. PODSYSTEM SERWEROWY DLA MASZYN WIRTUALNYCH	
1.	System musi być wyposażony w 8 procesorów 28-rdzeniowych klasy high-end posiadające wynik min 57 400  w benchmarku PassMark - CPU Mark znajdującym się na stronie internetowej http://www.cpubenchmark.net/high_end_cpus.html.
2.	System musi być wyposażony w minimum 3072 GB pamięci RAM. 

3.	System musi być wyposażony w minimum 8 portów 10 GbE RJ45.

4.	System musi być wyposażony w minimum 8 portów 10 GbE SFP+

5.	System musi być wyposażony w minimum 8 portów 25/10 GbE wraz w wkładkami.
6.	System musi być wyposażony w minimum 16 dysków NVME o pojemności 7.68 TB.
7.	System musi być wyposażony w minimum 4 porty o prędkości minimum 10/100 Base-T Ethernet do zarządzania zdalnego serwerem porty typu: IPMI.
8.	Redundatne zasilacze dla każdego serwera.	1.	System musi być wyposażony w 8 procesorów 28-rdzeniowych klasy high-end posiadające wynik min 57 400  w benchmarku PassMark - CPU Mark znajdującym się na stronie internetowej http://www.cpubenchmark.net/high_end_cpus.html.  TAK* / NIE*  
2.	System musi być wyposażony w minimum 3072 GB pamięci RAM.   TAK* / NIE*  
3.	System musi być wyposażony w minimum 8 portów 10 GbE RJ45.  TAK* / NIE*  
4.	System musi być wyposażony w minimum 8 portów 10 GbE SFP+  TAK* / NIE*  
5.	System musi być wyposażony w minimum 8 portów 25/10 GbE wraz w wkładkami.  TAK* / NIE*  
6.	System musi być wyposażony w minimum 16 dysków NVME o pojemności 7.68 TB.  TAK* / NIE*  
7.	System musi być wyposażony w minimum 4 porty o prędkości minimum 10/100 Base-T Ethernet do zarządzania zdalnego serwerem porty typu: IPMI.  TAK* / NIE*  
8.	Redundatne zasilacze dla każdego serwera.  TAK* / NIE*  	
IX. SERWIS GWARANCYJNY	IX. SERWIS GWARANCYJNY	
1.	Wymagany jest serwis gwarancyjny dla Systemu świadczony przez minimum 60 miesięcy.
2.	Wykonawca zapewni bezpośredni dostęp do Centrum serwisowego producenta rozwiązania poprzez: email, web, telefon.
3.	Wykonawca przystąpi do napraw gwarancyjnych przedmiotu zamówienia niezwłocznie (maksymalnie w ciągu 24 godz.) licząc od dnia zgłoszenia przez Zamawiającego. Dostępność serwisu 24 godz. na dobę przez 7 dni w tygodniu przez 365 dni w roku.

4.	Serwis zapewnia wsparcie w zakresie rozwiązywania problemów ze sprzętem i oprogramowaniem systemu oraz z dostarczonym wirtualizatorem.
5.	Wymiana uszkodzonych podzespołów – NBD od momentu potwierdzenia usterki.
6.	Wykonawca zapewni dostęp do poprawek (patch, hotfix, update) i nowych wersji oprogramowania (upgrade) w ramach wykupionego serwisu gwarancyjnego przez okres 5 lat.	1.	Wymagany jest serwis gwarancyjny dla Systemu świadczony przez minimum ..................... miesięcy.    
2.	Wymagany jest dostęp bezpośredni do Centrum serwisowego producenta rozwiązania poprzez: email, web, telefon.  TAK* / NIE*  
3.	 Wykonawca przystąpi do napraw gwarancyjnych przedmiotu zamówienia niezwłocznie (maksymalnie w ciągu 24 godz.) licząc od dnia zgłoszenia przez Zamawiającego. Dostępność serwisu 24 godz. na dobę przez 7 dni w tygodniu przez 365 dni w roku.  TAK* / NIE*  
4.	 Serwis zapewnia wsparcie w zakresie rozwiązywania problemów ze sprzętem i oprogramowaniem systemu oraz z dostarczonym wirtualizatorem. TAK* / NIE*  
5.	Wymiana uszkodzonych podzespołów – NBD od momentu potwierdzenia usterki.  TAK* / NIE*  
6.	Wykonawca zapewni dostęp do poprawek (patch, hotfix, update) i nowych wersji oprogramowania (upgrade) w ramach wykupionego serwisu gwarancyjnego przez okres ................ lat.   	
X. USŁUGI WDROŻENIOWE 	X. USŁUGI WDROŻENIOWE 
	
1.	Wykonawca przeprowadzi fizyczną instalację urządzeń w miejscu wskazanym przez Zamawiającego.
2.	Wykonawca wykona pełną konfigurację systemu.
	1.	Wykonawca przeprowadzi fizyczną instalację urządzeń w miejscu wskazanym przez Zamawiającego.  TAK* / NIE*  
2.	Wykonawca wykona pełną konfigurację systemu.  TAK* / NIE*  	
XI. INNE: 	XI.  INNE:	
Zamawiający wymaga aby dostarczone rozwiązanie było w pełni redundantne i kompletne, jeżeli do spełnienia wymagań, wymagane są dodatkowe licencje lub komponenty należy je dostarczyć.	Zamawiający wymaga aby dostarczone rozwiązanie było w pełni redundantne i kompletne, jeżeli do spełnienia wymagań, wymagane są dodatkowe licencje lub komponenty należy je dostarczyć.  TAK* / NIE*  	
DODATKOWE FUNKCJONALNOŚCI	DODATKOWE FUNKCJONALNOŚCI	
1.	Jeżeli rozwiązanie wspiera dwa różne hypervisory – 10%
2.	Jeżeli rozwiązanie wspiera więcej niż dwa hypervisory (dodatkowe) – 10% 

3.	Deduplikacja i kompresja muszą być od siebie niezależne. Oznacza to, że musi być możliwość włączenia tylko kompresji lub tylko deduplikacji, włączenia obydwu mechanizmów jednocześnie lub wyłączenie obydwu. Powyższe ustawienia muszą być konfigurowalne osobno dla poszczególnych maszyn wirtualnych – 10%
4.	Rozwiązanie musi umożliwiać tworzenie klastrów składających się z węzłów różnego typu i o różnej konfiguracji (RAM, CPU, HDD, SSD, NVMe), a także zawierające komponenty sprzętowe różnej generacji (np. CPU różnych generacji) – 10%
	1.	rozwiązanie wspiera ..................... różne hypervisory; *
2.	rozwiązanie wspiera ................... (więcej niż dwa hypervisory dodatkowe); *
3.	deduplikacja i kompresja są od siebie niezależne. Oznacza to, że musi być możliwość włączenia tylko kompresji lub tylko deduplikacji, włączenia obydwu mechanizmów jednocześnie lub wyłączenie obydwu. Powyższe ustawienia muszą być konfigurowalne osobno dla poszczególnych maszyn wirtualnych; TAK* / NIE*
4.	rozwiązanie umożliwia tworzenie klastrów składających się z węzłów różnego typu i o różnej konfiguracji (RAM, CPU, HDD, SSD, NVMe), a także zawierające komponenty sprzętowe różnej generacji (np. CPU różnych generacji). TAK* / NIE*

Oświadczam/my, że oferowane przedmioty są fabrycznie nowe, nieużywane oraz pochodzą z bieżącej produkcji
2024 roku.*
Dokument należy złożyć w postaci elektronicznej opatrzonej kwalifikowanym podpisem elektronicznym, przez osobę uprawnioną.
............................................................................................................
                         (podpis osoby upoważnionej do reprezentowania Wykonawcy) 
UWAGA! 
        Wykonawca obowiązany jest, w kolumnie B „Specyfikacji oferowanego przedmiotu zamówienia”, wpisać oferowany przedmiot zamówienia poprzez jednoznaczne określenie jego nazwy, typu oraz producenta (oferowanego sprzętu) oraz dokładnie opisać jego parametry techniczne, cechy funkcjonalne lub charakterystykę w odniesieniu do pozycji wskazanych w kolumnie A. 

TAK* / NIE*  niepotrzebne skreślić / wypełnić właściwe