dostawa macierzy dyskowej, serwera oraz oprogramowania do wirtualizacji dla Sądu Okręgowego w Tarnowie

Opis przedmiotu przetargu: I. Macierz dyskowa 1. Macierz musi posiadać moduły odpowiedzialne za obsługę protokołów iSCSI, CIFS, NFS (wersje V2, V3) oraz FTP. 2. Macierz musi być wyposażona w redundantne kontrolery odpowiedzialne za obsługę zarządzanej przestrzeni dyskowej, jej konfigurację, liczenie RAID oraz obsługę protokołów wymienionych w punkcie 1. 3. Moduły obsługujące przestrzeń dyskową muszą być wyposażone w pamięć o pojemności, co najmniej 4 GB DDR3 każdy. Pamięć cache zapisu musi być zabezpieczona mechanizmem mirroringu. 4. Wymagana jest redundancja wszystkich komponentów macierzy, tj.: kontrolerów, ścieżek do dysków, zasilaczy, wentylatorów, podwójnych połączeń pomiędzy kontrolerami macierzowymi, służących do mirrorowania zawartości pamięci cache. 5. Macierz musi umożliwiać zabezpieczenie danych rezydujących w pamięci cache zapisu przed ich utratą, na wypadek zaniku zasilania, na czas nieograniczony np. mechanizmem zapisu zawartość pamięci cache zapisu na dyski wewnętrzne. 6. Macierz musi współpracować równocześnie z dyskami SAS, jak i tańszymi dyskami Near Line SAS. Macierz musi być wyposażona, w co najmniej 6 dysków SAS o pojemności 600 GB SAS i prędkości obrotowej 15k rpm. 7. Macierz musi umożliwiać pracę dysków SAS oraz Near Line SAS w jednej półce dyskowej. 8. Macierz musi pozwalać na rozbudowę, do co najmniej 96 dysków twardych. Dodawanie kolejnych dysków, jak i kolejnych półek dyskowych powinno odbywać się w trybie on-line. 9. Każdy dysk musi posiadać dwa porty do komunikacji, po jednym do każdego kontrolera. Połączenia między dyskami, a kontrolerami muszą być wykonane w technologii SAS 6Gbps. 10. Macierz musi zapewniać wsparcie dla następujących poziomów RAID: 10, 5, 6. 11. Macierz musi pozwalać na dedykowanie globalnych dysków Hot Spare, z możliwością dowolnego rozmieszczenia ich w obrębie macierzy. 12. Macierz musi mieć możliwość tymczasowego wyłączenia nieużywanych dysków NL SAS (drive spindown) w celu oszczędzania energii elektrycznej. 13. Macierz musi obsługiwać mechanizmy LUN Masking i LUN Mapping. 14. Macierz musi pozwalać na tworzenie, co najmniej 256 LUN-ów iSCSI. 15. Macierz powinna oferować funkcjonalność obsługiwania, co najmniej 10 tzw. target-ów iSCSI na każdym z dostępnych portów Ethernet. 16. Macierz musi oferować funkcjonalność rozszerzania grup RAID o dodatkowe dyski on-line, bez przerwy w dostępie do LUN-ów rezydujących na tej grupie RAID. 17. Macierz musi pozwalać na migrowanie LUN-ów pomiędzy różnymi typami grup RAID w trybie on-line, z ciągłym dostępem do danych dla serwerów korzystających z migrującego LUNa. 18. Upgrade firmware-u i oprogramowania kontrolerów macierzy musi odbywać się bezprzerwowo, z ciągłym dostępem do danych. 19. Oferowane urządzenie musi być wyposażone, w co najmniej: a. 4 porty typu 1GbE miedziany do komunikacji z hostami, b. 2 porty typu 1GbE miedziany do zarządzania. c. 4 porty SAS 6Gbps do komunikacji z półkami dyskowymi. d. 2 porty USB. 20. Oferowane urządzenie musi umożliwiać rozbudowę o dodatkowe 8 portów typu 1GbE miedziany do komunikacji z hostami. 21. Urządzenie powinno zapewniać wsparcie dla funkcjonalności agregacji portów IEEE 802.3ad lub Cisco EtherChannel oraz definiowania portów VLAN IEEE 802.1q. 22. Macierz powinna umożliwiać utworzenie przynajmniej 256 systemów plików. 23. Macierz powinna zapewniać utworzenie przynajmniej 300 udziałów CIFS oraz 300 exportów NFS. 24. Urządzenie NAS ma obsługiwać mechanizm snapshot-ów w trybie do zapisu i odczytu, wykonywanych z poziomu macierzy. Wymagane jest, aby macierz pozwalała na wykonywanie, co najmniej 96 kopii migawkowych, istniejących na niej systemów plików. Mechanizm snapshot-ów ma umożliwiać przywrócenie zawartości całego systemu plików bazując na jego snapshot-cie. Licencja umożliwiająca wykorzystanie powyższej funkcjonalności jest obecnie przedmiotem oferty. 25. Dane z kopii migawkowych (wskaźniki itp.) mają być składowane na osobnych dedykowanych zasobach dyskowych, a nie razem z danymi produkcyjnymi. 26. Operacje wykonywane (tworzenie, usuwanie) na snapshotach nie mogą wpływać na stan danych produkcyjnych, w tym nie mogą powodować fragmentacji zasobów produkcyjnych. 27. Rozwiązanie ma pozwalać na automatyczne zwiększanie przestrzeni dla kopii migawkowych. 28. Przepełnienie przestrzeni dla kopii migawkowych nie może powodować błędów zapisu na przestrzeń produkcyjną. 29. Możliwość definiowania automatycznej polityki tworzenia kopii migawkowych z wykorzystaniem interwału czasowego. 30. W przypadku odtworzenia danych z dowolnej kopii migawkowej, urządzenie musi pozwalać na poprawne zachowanie także wcześniejszych jak i późniejszych snapshotów, z zachowaniem możliwości kolejnego odtworzenia danych zarówno ze wszystkich istniejących (starszych i nowszych) kopii dostępnych dla danego zasobu. 31. Obsługa mechanizmu zagnieżdżania systemów plików dla użytkowników NFS i CIFS, gdzie wiele osobnych systemów plików jest prezentowane do użytkowników, jako jeden system plikowy. 32. Dla LUN-ów będących widocznych dla serwerów po protokole iSCSI, zamawiający wymaga funkcjonalności tworzenia snapshot-ów pojedynczych LUN-ów (kopii point in time), wykonywanych z poziomu macierzy. 33. Możliwość integracji snapshot-ów z mechanizmem VSS Microsoft. Licencja umożliwiająca wykorzystanie powyższej funkcjonalności nie jest obecnie przedmiotem oferty. 34. Macierz musi zapewniać mechanizm thin provisioning, który polega na udostępnianiu większej przestrzeni logicznej niż jest to fizycznie alokowane w momencie tworzenia zasobu. W przypadku zbliżenia się do fizycznych granic systemu plików, musi istnieć możliwość automatycznego jego rozszerzenia bez konieczności interwencji administratora. Licencja umożliwiająca wykorzystanie powyższej funkcjonalności jest obecnie przedmiotem oferty. 35. Macierz musi zapewniać mechanizm deduplikacji wraz z kompresjią danych dla systemów plików o wielkości, co najmniej 16TB w celu optymalizacji wykorzystania przestrzeni dyskowej. Licencja umożliwiająca wykorzystanie powyższej funkcjonalności jest obecnie przedmiotem oferty. 36. Macierz musi wspierać mechanizm zdalnej replikacji z poziomu macierzy na drugą zapasową macierz, w trybie synchronicznym lub asynchronicznym). Licencja umożliwiająca wykorzystanie powyższych funkcjonalności nie jest przedmiotem oferty. 37. Urządzenie musi oferować funkcjonalność retencji (WORM) na poziomie pojedynczych plików, jak i całych systemów plików. Licencja umożliwiająca wykorzystanie powyższych funkcjonalności nie jest przedmiotem oferty. 38. Serwer musi obsługiwać protokół DFS. Serwer powinien móc pracować zarówno we współpracy z innymi serwerami DFS, jak również jako niezależny serwer DFS root. 39. Dla celów współpracy z systemem backupu, serwer plików musi obsługiwać protokół NDMP w wersjach 1 - 4. 40. Serwer plikowy ma również współpracować z rozwiązaniami antywirusowymi firm trzecich (np. McAfee, Norton, Trend, CA, Sophos). Licencja umożliwiająca wykorzystanie powyższych funkcjonalności nie jest przedmiotem oferty. 41. Urządzenie musi współpracować zarówno z protokołem Active Directory, LDAP, Kerberos, Secure NFS jak i NIS. 42. Macierz powinna posiadać wsparcie dla systemów operacyjnych takich jak: Microsoft Windows Server 2003, 2008, 2008 R2+, Windows 7, Windows Vista, Microsoft Hyper-V, VMware ESX, RedHat Enterprise Linux, Novell Suse Enterprise Linux, Solaris 10 x86. 43. Macierz musi umożliwiać zarządzanie zarówno z poziomu linii komend (CLI), jak również poprzez jeden interfejs graficzny (GUI). 44. Oprogramowanie do zarządzania macierzą musi rezydować na macierzy, bez konieczności dedykowania osobnego serwera dla potrzeb obsługi oprogramowania zarządzającego. 45. Dostarczone urządzenie ma być produktem fabrycznie nowym, dostarczonym poprzez autoryzowany kanał sprzedaży producenta na terenie Polski. 46. Macierz musi być objęta gwarancją na sprzęt jak i oprogramowanie przynajmniej na trzy lata. Gwarancja ma być świadczona w trybie 24x7 z 4 - godzinnym czasem reakcji. 47. Wymaga się, aby uszkodzone dyski twarde, po wymienieniu na nowe, pozostawały u zamawiającego. 48. Wymaga się, aby macierz była dostarczona wraz z oprogramowaniem umożliwiającym zdalne monitorowanie macierzy przez organizację serwisową producenta. Usługa taka ma być świadczona w ramach oferowanej gwarancji. II. Serwer Parametr Charakterystyka (wymagania minimalne) Obudowa Maksymalnie 2U do instalacji w standardowej szafie RACK 19 cali, dostarczona wraz z szynami. Płyta główna Płyta główna z możliwością zainstalowania do dwóch procesorów, dwu, cztero, sześciordzeniowych. Płyta główna musi być zaprojektowana przez producenta serwera i oznaczona jego znakiem firmowym Chipset Dedykowany przez producenta procesora do pracy w serwerach dwuprocesorowych Procesor Dwa procesory sześciordzeniowe klasy x86 dedykowane do pracy w serwerach zaprojektowane do pracy w układach dwuprocesorowych, taktowane zegarem co najmniej 2.66GHz, pamięć L3 12MB każdy lub procesor równoważny wydajnościowo. W przypadku zaoferowania procesora równoważnego Zamawiający zastrzega możliwość przeprowadzenia testów i w związku z tym, oferent zobowiązany będzie do dostarczenia zamawiającemu oprogramowania testującego. RAM 16GB DDR3 LV RDIMM, płyta główna powinna umożliwiać obsługę do 128GB Zabezpieczenia pamięci RAM ECC, Memory Mirror Gniazda PCI Minimum 3 złącza PCIe drugiej generacji w tym minimum 1 x PCI-E x8 i 2 x PCI-E x4. Interfejsy sieciowe Minimum 2 wbudowane porty typu 10, 100, 1000 RJ-45. Napęd optyczny Wewnętrzny napęd DVD-ROM Dyski twarde Możliwość instalacji dysków SATA, SAS, SSD. Zainstalowane 4 dyski 450GB typu Hot-Plug SAS 15krpm skonfigurowane w RAID10. Możliwość instalacji dodatkowych 4 dysków twardych Hot-Plug. Kontroler RAID Dedykowany, posiadający minimum 256MB pamięci cache z podtrzymaniem bateryjnym umożliwiający następujące konfiguracje RAID: 0, 1, 5, 10 ,50, 6, 60 Porty 6 x USB 2.0 z czego 2 na przednim panelu obudowy, 2 na tylnym panelu obudowy i dwa wewnętrzne, VGA Video Zintegrowana karta graficzna, umożliwiająca rozdzielczość min. 1280x1024. Zasilacze Redundantne minimum 750W każdy Bezpieczeństwo Zintegrowany z płytą główną moduł TPM. Napęd USB Wewnętrzny klucz USB umożliwiający instalację hypervisora Diagnostyka Panel LCD umieszczony na froncie obudowy, umożliwiający wyświetlenie informacji o stanie procesora, pamięci, dysków, BIOSu. Karta Zarządzania Niezależna od zainstalowanego na serwerze systemu operacyjnego posiadająca dedykowane złącze RJ-45 i umożliwiająca: 1. zdalny dostęp do graficznego interfejsu Web karty zarządzającej 2. zdalne monitorowanie i informowanie o statusie serwera (m.in. prędkości obrotowej wentylatorów, konfiguracji serwera, ) 3. szyfrowane połączenie (SSLv3) oraz autentykacje i autoryzację użytkownika 4. możliwość podmontowania zdalnych wirtualnych napędów 5. wirtualną konsolę z dostępem do myszy, klawiatury 6. wsparcie dla IPv6 7. wsparcie dla WSMAN (Web Service for Managament); SNMP; IPMI2.0, VLAN tagging, Telnet, SSH 8. możliwość zdalnego monitorowania w czasie rzeczywistym poboru prądu przez serwer 9. możliwość zdalnego ustawienia limitu poboru prądu przez konkretny serwer 10. integracja z Active Directory 11. możliwość obsługi przez dwóch administratorów jednocześnie 12. wsparcie dla dynamic DNS 13. wysyłanie do administratora maila z powiadomieniem o awarii lub zmianie konfiguracji sprzętowej 14. możliwość podłączenia lokalnego poprzez złącze RS-232 Certyfikaty Serwer musi być wyprodukowany zgodnie z normą ISO-9001 oraz ISO-14001 oraz deklaracją CE. Oferowany serwer musi znajdować się na liście Windows Server Catalog i posiadać status Certified for Windows dla MS Windows Server 2008 w wersji x86, x64 i R2 x64. Warunki gwarancji Przynajmniej trzy lata gwarancji z czasem reakcji do czterech godzin od zgłoszenia. Firma serwisująca musi posiadać ISO 9001:2000 na świadczenie usług serwisowych oraz posiadać autoryzację producenta serwera. W przypadku awarii dysku twardego uszkodzony nośnik pozostaje u Zamawiającego. Dokumentacja użytkownika Zamawiający wymaga dokumentacji w języku polskim lub angielskim. Zamawiający wymaga możliwość telefonicznego sprawdzenia konfiguracji sprzętowej serwera oraz warunków gwarancji po podaniu numeru seryjnego bezpośrednio u producenta lub jego przedstawiciela. III. Oprogramowanie do wirtualizacji 1. Warstwa wirtualizacji musi być zainstalowana bezpośrednio na sprzęcie fizycznym bez dodatkowych pośredniczących systemów operacyjnych 2. Licencje powinny obejmować min. trzy co najmniej dwuprocesorowe serwery i powinny umożliwiać obsługę 32 GB pamięci wirtualnej vRAM per procesor czyli 192 GB pamięci wirtualnej vRAM łącznie (pamięć wirtualna vRAM to pamięć, która jest wykorzystywana przez włączone wirtualne maszyny). 3. Rozwiązanie musi zapewnić możliwość obsługi wielu instancji systemów operacyjnych na jednym serwerze fizycznym i powinno się charakteryzować maksymalnym możliwym stopniem konsolidacji sprzętowej. 4. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych 1-8 procesorowych. 5. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z możliwością przydzielenia do 1 TB pamięci operacyjnej RAM. 6. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z których każda może mieć 1-10 wirtualnych kart sieciowych. 7. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z których każda może mieć co najmniej 4 porty szeregowe i 3 porty równoległe i 20 urządzeń USB . 8. Rozwiązanie musi umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku wydajności i dostępności pozostałych wybranych usług. 9. Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta platformy sprzętowej. 10. Polityka licencjonowania musi umożliwiać przenoszenie licencji na oprogramowanie do wirtualizacji pomiędzy serwerami różnych producentów z zachowaniem wsparcia technicznego i zmianą wersji oprogramowania na niższą (downgrade). Licencjonowanie nie może odbywać się w trybie OEM. 11. Rozwiązanie musi wspierać następujące systemy operacyjne: MS-DOS 6.22, Windows 3.1, Windows 95, Windows 98, Windows XP, Windows Vista , Windows NT 4.0, Windows 2000, Windows Server 2003, Windows Server 2008, Windows 7, SLES 10, SLES9, SLES8, Ubuntu 7.04, RHEL 5, RHEL 4, RHEL3, RHEL 2.1, Solaris 10, Solaris 9, Solaris 8, OS 2 Warp 4.0, NetWare 6.5, NetWare 6.0, NetWare 6.1, Debian, CentOS, FreeBSD, Asianux, Ubuntu 7.04, SCO OpenServer, SCO Unixware, FreeBSD, Mac OS X. 12. Rozwiązanie musi umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn wirtualnych niż fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego współczynnika konsolidacji. 13. Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów dyskowych niż jest fizycznie zarezerwowane na dyskach lokalnych serwera lub na macierzy. 14. Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami wirtualnymi i do konfigurowania innych funkcjonalności. Centralna konsola graficzna powinna mieć możliwość działania zarówno jako aplikacja na maszynie fizycznej lub wirtualnej jak i jako gotowa, wstępnie skonfigurowana maszyna wirtualna tzw. virtual appliance. 15. Rozwiązanie musi zapewnić możliwość bieżącego monitorowania wykorzystania zasobów fizycznych infrastruktury wirtualnej (np. wykorzystanie procesorów, pamięci RAM, wykorzystanie przestrzeni na dyskach, wolumenach) oraz przechowywać i wyświetlać dane maksymalnie sprzed roku. 16. Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii migawkowych instancji systemów operacyjnych (tzw. snapshot) na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy. 17. Oprogramowanie do wirtualizacji musi zapewnić możliwość klonowania systemów operacyjnych wraz z ich pełną konfiguracją i danymi. 18. Oprogramowanie do wirtualizacji oraz oprogramowanie zarządzające musi posiadać możliwość integracji z usługami katalogowymi Microsoft Active Directory. 19. Rozwiązanie musi zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej (np. wgrywania krytycznych poprawek) bez potrzeby wyłączania wirtualnych maszyn. 20. Rozwiązanie musi zapewniać taki mechanizm bezpiecznego uaktualniania aplikacji i systemów operacyjnych wirtualnych maszyn, poprzez który można wprowadzać poprawki na pojedyncze wirtualne maszyny jak i na całe grupy wirtualnych maszyn. Dla bezpieczeństwa wspomniany mechanizm musi pozwalać na automatyczne wykonywanie kopii migawkowych przed aktualizacją. 21. Oprogramowanie do wirtualizacji musi obsługiwać przełączenie ścieżek SAN (bez utraty komunikacji) w przypadku awarii jednej z kilku dostępnych ścieżek. 22. Rozwiązanie musi mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi. Mechanizm powinien umożliwiać 4 lub więcej takich procesów przenoszenia jednocześnie. 23. Musi zostać zapewniona odpowiednia redundancja i taki mechanizm (wysokiej dostępności HA) aby w przypadku awarii lub niedostępności serwera fizycznego wybrane przez administratora i uruchomione nim wirtualne maszyny zostały uruchomione na innych serwerach z zainstalowanym oprogramowaniem wirtualizacyjnym. 24. System musi posiadać funkcjonalność wirtualnego przełącznika (virtual switch) umożliwiającego tworzenie sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta, a także na zewnątrz sieci fizycznej. Pojedynczy przełącznik wirtualny powinien mieć możliwość konfiguracji do 4000 portów. 25. Pojedynczy wirtualny przełącznik musi posiadać możliwość przyłączania do niego dwóch i więcej fizycznych kart sieciowych aby zapewnić bezpieczeństwo połączenia ethernetowego w razie awarii karty sieciowej. 26. Wirtualne przełączniki muszą obsługiwać wirtualne sieci lokalne (VLAN)