Koleczkowo: ZAKUP I WDROŻENIE ZEWNĘTRZNEGO INFORMATYCZNEGO SYSTEMU ARCHIWIZACYJNEGO
Numer ogłoszenia: 281124 - 2013; data zamieszczenia: 18.07.2013
OGŁOSZENIE O UDZIELENIU ZAMÓWIENIA - Dostawy

Zamieszczanie ogłoszenia: obowiązkowe.

Ogłoszenie dotyczy: zamówienia publicznego.

Czy zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych: tak, numer ogłoszenia w BZP: 100675 - 2013r.

Czy w Biuletynie Zamówień Publicznych zostało zamieszczone ogłoszenie o zmianie ogłoszenia: nie.

SEKCJA I: ZAMAWIAJĄCY

I. 1) NAZWA I ADRES: "EKO DOLINA" Sp. z o.o., Al. Parku Krajobrazowego 99, Łężyce, 84-207 Koleczkowo, woj. pomorskie, tel. 058 6725000, faks 058 6727474.

I. 2) RODZAJ ZAMAWIAJĄCEGO: Podmiot prawa publicznego.

SEKCJA II: PRZEDMIOT ZAMÓWIENIA

II.1) Nazwa nadana zamówieniu przez zamawiającego: ZAKUP I WDROŻENIE ZEWNĘTRZNEGO INFORMATYCZNEGO SYSTEMU ARCHIWIZACYJNEGO.

II.2) Rodzaj zamówienia: Dostawy.

II.3) Określenie przedmiotu zamówienia: Przedmiotem zamówienia jest dostarczenie serwera i licencji na oprogramowanie archiwizacyjne wraz z jego zainstalowaniem i uruchomieniem. Na przedmiot zamówienia składa się: Dostarczenie i uruchomienie serwera do obsługi oprogramowania archiwizacyjnego i archiwizacji danych. Dostarczenie i zainstalowanie licencji oprogramowania archiwizacyjnego. Dostarczenie i uruchomienie serwera do obsługi oprogramowania archiwizacyjnego i archiwizacji danych. Dostarczenie i uruchomienie serwera o następujących parametrach: 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 zainstalowanymi dwoma ośmiordzeniowymi procesorami komunikujących się poprzez współdzieloną szynę.; Chipset; Dedykowany przez producenta procesora do pracy w serwerach dwuprocesorowych; Procesor; Dwa procesory ośmiordzeniowe klasy x86 dedykowane do pracy w serwerach osiągające w teście SPECintrate2006 wynik minimum 285 punktów.; RAM; 32GB wyposażone w ECC dostępne w formie czterech modułów po 8GB każdy, 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 1x PCIE x8 i 2x PCIE x4.; Interfejsy sieciowe; Minimum 2 wbudowane porty typu 10 100 1000 RJ 45; Napęd optyczny; Wewnętrzny napęd DVDROM; Dyski twarde; Możliwość instalacji dysków SATA, SAS, SSD. Zainstalowane 6 dysków typu Near line SAS 3,5cali o pojemności 2TB każdy w konfiguracji RAID5. System powinien zapewniać wsparcie dla technologii hot plug dla każdego z dysków.; Kontroler RAID; Dedykowany kontroler RAID. Możliwe konfiguracje 0, 1, 5, 6 oraz 10 Kontroler powinien być wyposażony w minimum 512MB pamięci podręcznej której zawartość jest podtrzymywana także w przypadku niedostępności zasilania serwera.; Porty; 6x USB 2.0 z czego 2 na przednim panelu obudowy, 2 na tylnym panelu obudowy i dwa wewnętrzne, 2x RJ 45, VGA; Video; Karta graficzna, umożliwiająca rozdzielczość min. 1280x1024.; Zasilacz; Redundantne minimum 750W każdy; Bezpieczeństwo; Zintegrowany z płytą główną moduł TPM.; Diagnostyka; Panel LCD umieszczony na froncie obudowy, umożliwiający przynajmniej wyświetlenie informacji o stanie procesora, pamięci, dysków, BIOSu.; Karta Zarządzania; Możliwość instalacji karty zarządzającej niezależnej od zainstalowanego na serwerze systemu operacyjnego posiadającej dedykowane złącze RJ 45 i umożliwiającej: zdalny dostęp do graficznego interfejsu Web karty zarządzającej zdalne monitorowanie i informowanie o statusie serwera (m.in. 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 WSMAN (Web Service for Management); 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; Certyfikaty; Deklaracja 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 na serwer z czasem reakcji na następny dzień roboczy. W przypadku awarii dysku twardego uszkodzony nośnik pozostaje u Zamawiającego.; Dokumentacja użytkownika; Zamawiający wymaga dokumentacji w języku polskim.; Dostarczenie i zainstalowanie licencji oprogramowania archiwizacyjnego wraz ze wsparciem technicznym Wymagania ogólne: System archiwizacji musi posiadać możliwość backupu 3TB danych w podstawowej licencji (z możliwością rozbudowy do co najmniej 12 TB. System kopii zapasowych w architekturze klient serwer, z centralnym serwerem zarządzającym procesem backupu oraz klientami (agentami) instalowanymi na maszynach w sieci. System kopii zapasowych umożliwiający prostą promocję każdego z klientów (niezależnie od wykorzystywanego systemu operacyjnego) zarejestrowanych w centralnym systemie backupu do funkcji serwera mediów, który może posłużyć do składowania backupu z innych klientów. Funkcja ta ma umożliwiać promocję klienta do funkcji serwera mediów z wykorzystaniem dedykowanej funkcji interfaceu Web, bez konieczności modyfikowania plików konfiguracyjnych klienta oraz serwera a także zmian na samym kliencie. Funkcja serwera mediów musi umożliwiać wykorzystanie zarówno lokalnych zasobów dyskowych każdego z klientów oraz napędu taśmowego i biblioteki taśmowej do nich podłączonych celem zapisania na nich backupu z pozostałych klientów. Funkcjonalność promocji klienta do serwera mediów może być ograniczona jedynie zakresem licencji. System kopii zapasowych musi mieć możliwość wykonywania backupu na dysk, na taśmę z wykorzystaniem napędu taśmowego oraz biblioteki taśmowej a także do chmury utworzonej z serwerów backupu zainstalowanych w zdalnych lokalizacjach. System musi posiadać wbudowany mechanizm deduplikacji pozwalający na zaoszczędzenie ilości miejsca na dysku poprzez wyszukiwanie bloków zapisanych na nośniku w poprzednim zadaniu backupu. System musi umożliwiać zarządzanie licencjami poprzez interface Web. Administrator musi mieć możliwość dodawania dowolnej licencji. Musi istnieć możliwość dodawania (rozbudowy) poszczególnych funkcjonalności oprogramowania bez konieczności uruchamiania ponownie żadnego z komponentów oprogramowania bez konieczności restartu jakichkolwiek usług wchodzących w skład oprogramowania oraz jakichkolwiek maszyn wchodzących w skład systemu kopii bezpieczeństwa. System archiwizacji musi mieć możliwość obsługi nielimitowanej ilości klientów backupu, wliczając w to agentów systemu plików oraz agentów dla hypervisorów. Wymagania dla centralnego serwera backupu Centralny serwer backupu musi mieć możliwość instalacji na dowolnym open sourceowym systemie operacyjnym. Serwer backupu musi być instalowany na systemie Linux. Instalator centralnego serwera backupu musi być dostarczony jako pakiet RPM (dla systemów zgodnych z Red Hat), pakiet DEB (dla systemów zgodnych z Debian) oraz jako archiwum tar.gz dla pozostałych. Zarządzanie serwerem backupu musi być możliwe poprzez przeglądarkę internetową. Funkcjonalność ta musi być dostępna do pobrania z serwerów producenta w postaci odrębnego instalatora. Instalator systemu zarządzania poprzez przeglądarkę musi być dostarczony minimum jako: pakiet RPM (dla systemów zgodnych z Red Hat), pakiet DEB (dla systemów zgodnych z Debian) oraz jako archiwum tar.gz dla pozostałych. Interface systemu dostępny przez przeglądarkę za pomocą szyfrowanego protokołu HTTPS. W domyślnej konfiguracji, interface dostępny przez przeglądarkę nie może wykorzystywać portów TCP niższych niż 1024, niedopuszczalne jest, aby interface nasłuchiwał na portach 80 oraz 443.Administrator musi mieć możliwość zdefiniowania dowolnego portu TCP, na którym nasłuchiwać będzie interface dostępny poprzez przeglądarkę. W domyślnej konfiguracji oprogramowania, autoryzacja do systemu zarządzania musi być możliwa z konta użytkownika Root, gdzie hasło ma być puste. System musi umożliwiać utworzenie dowolnej ilości kont użytkowników. z możliwością przypisania roli odzwierciedlającej poziom uprawnień. System musi oferować minimum 3 rodzaje kont użytkowników systemu: Użytkownik nie może tworzyć, usuwać ani modyfikować jakichkolwiek obiektów w systemie, ma prawo jedynie do odtwarzania kopii zapasowych. Operator może uruchamiać zadania backupu, z uprawnieniami tylko do odczytu ma dostęp do konfiguracji systemu, Administrator może wykonywać wszystkie typy operacji w systemie w tym tworzyć, modyfikować oraz usuwać obiekty i konta użytkowników, Serwer backupu musi umożliwiać dwukierunkową komunikację z agentami. zarówno za pomocą adresu IP jak również z wykorzystaniem nazwy DNS. System musi umożliwiać replikację danych pomiędzy wieloma serwerami backupu zlokalizowanymi w jakichkolwiek lokalizacjach na terenie zakładu prowadzonego przez Zamawiającego za pośrednictwem sieci LAN oraz łącz WAN. Proces replikacji danych pomiędzy serwerami backupu musi mieć możliwość definiowania minimum takich właściwości jak: dane przeznaczone do replikacji z dokładnością do pojedynczego zasobu dyskowego, częstotliwość z jaką replikacja będzie się odbywać z dokładnością do minuty, momentu zakończenia replikacji (musi istnieć możliwość zdefiniowania daty końcowej, wyłączenia daty końcowej replikacja ciągła oraz zdefiniowania ilości wystąpień zadania replikacji, po których polityka przestanie być aktywna), retencji z dokładnością do jednego dnia. Produkt musi posiadać możliwość replikacji danych pomiędzy lokalnymi zasobami dyskowymi, administrator musi mieć możliwość zwielokrotnienia tych samych danych na wielu zasobach dyskowych celem ich zabezpieczenia na wypadek awarii pojedynczego zasobu dyskowego. Proces replikacji danych pomiędzy lokalnymi zasobami dyskowymi musi być wyzwalany na żądanie administratora. Administrator przed rozpoczęciem replikacji musi być w stanie określić: źródłowy logiczny zbiór danych do replikacji (z dokładnością do pojedynczego pliku), docelowy zasób dyskowy, na który dane mają zostać zreplikowane, czas retencji dla danych replikowanych, włączenie wyłączenie raportowania na email o szczegółach wykonania zadania replikacji, wyłączenie aktualizacji indeksu danych o dane zreplikowane, ustawienie limitu czasowego po przekroczeniu, którego proces replikacji zostanie zatrzymany. System musi umożliwiać prostą rozbudowę o opcję związaną z szyfrowaniem backupu z wykorzystaniem przynajmniej takich algorytmów jak 3DES (z PCBC), Blowfish oraz AES256 za pomocą pojedynczego pliku licencji instalowanej na serwerze backupu. Klucze szyfrujące nie mogą być zapisywane razem z danymi backupowanymi. Klucze muszą być przechowywane na kliencie (agencie) a nie na centralnym serwerze backupu. Funkcjonalność szyfrowania danych musi zabezpieczać zarówno dane przesyłane przez sieć jak również dane zapisywane na centralnym serwerze backupu. Serwer backupu musi mieć możliwość definiowania maksymalnej ilości jednoczesnych operacji dla zasobu dyskowego, przy czym wartość maksymalna musi być nie niższa niż 15. System musi umożliwiać odtwarzanie backupu z możliwością określenia: czy odtworzone mają być oryginalne prawa na plikach, daty modyfikacji, ACL w systemie POSIX oraz atrybutów rozszerzonych Linux, czy nadpisywać pliki, jeśli istnieją na docelowej maszynie, czy nadpisywać pliki, jeśli są nowsze niż te, które znajdują się w backupie. Podczas odtwarzania, administrator musi ponadto mieć możliwość zdefiniowania systemu innego niż centralny system backupu, który będzie źródłem dla procesu odtwarzania. System musi oferować możliwość kompresji danych backupu przed przesłaniem ich poprzez sieć na backup serwer, możliwość ta musi istnieć jako opcja dla każdego z definiowanych zadań backupu. Algorytm kompresji wykorzystywany do kompresji backupu bazujący na algorytmie LZ77, niedopuszczalne jest stosowanie zamkniętych algorytmów kompresji danych. Centralny serwer backupu musi być wyposażony w mechanizm reindeksacji istniejących taśm z backupem. W przypadku uszkodzenia indeksu, funkcja ta musi mieć możliwość zaindeksowania taśm utworzonych zarówno na danym centralnym serwerze backupu, jak i na każdym innym centralnym serwerze backupu wchodzącym w skład środowiska backupu. Centralny serwer backupu musi być wyposażony w mechanizm reindeksacji istniejących zasobów dyskowych z backupem w przypadku uszkodzenia indeksu. Funkcja ta ma mieć możliwość zaindeksowania dysków z danymi zarówno na danym centralnym serwerze backupu, jak i na każdym innym centralnym serwerze backupu wchodzącym w skład środowiska backupu. Mechanizm reindeksacji dysków musi umożliwiać administratorowi określenie takich właściwości procesu przed jego rozpoczęciem jak: w przypadku znanych dysków: wybór źródłowego zasobu dyskowego, wybór czy rozpocząć indeksację od momentu jej przerwania czy od początku nośnika oraz czy po zakończeniu procesu przesłać powiadomienie do administratora drogą elektroniczną z podsumowaniem procesu indeksacji, w przypadku nieznanych dysków: wybór hosta należącego do systemu backupu, do którego podłączony jest zasób dyskowy, definicja nazwy dla nowoutworzonego zasobu dyskowego po indeksacji, wskazanie pełnej ścieżki do indeksowanych danych, zdefiniowanie wielkości wolumenu z dokładnością do 1 megabajta, wybór czy rozpocząć indeksację od momentu jej przerwania czy od początku nośnika oraz czy po zakończeniu procesu przesłać powiadomienie do administratora drogą elektroniczną z podsumowaniem procesu indeksacji. System musi być wyposażony w mechanizm nawigacji, który umożliwia przeglądanie przez przeglądarkę Web zawartości dysków twardych wszystkich klientów zarejestrowanych w centralnym serwerze backupu oraz dodatkowo jego własne dane. Dane mają być wyświetlane w formie drzewa katalogów z możliwością przeglądania ich zawartości. Funkcjonalność ta musi działać niezależnie od systemu operacyjnego klienta oraz serwera. W każdym przypadku administrator ma mieć możliwość przeglądania plików i katalogów oraz weryfikacji poprawności komunikacji pomiędzy klientem a serwerem. Mechanizm nawigacji musi oferować możliwość weryfikacji, czy na stacji poprawnie zainstalowano agenta do hot backupu aplikacji (agent ma wówczas w drzewie przypisanym do danego klienta wyświetlać listę takich aplikacji). System musi być wyposażony w mechanizm automatycznego wykrywania urządzeń takich jak napędy i biblioteki taśmowe, które zostały podłączone do centralnego systemu backupu. Funkcja ta nie może być związana z koniecznością uprzedniej instalacji sterowników do obsługi danego urządzenia. Wymagania dla agenta backupu Agent backupu musi wspierać hot backup (backup w czasie pracy) dla platformy wirtualizacyjnej VMware Infrastructure w wersjach ESX 3.0, 3.5, ESXi 3.x, Virtual Center 2.0, 2.5, Microsoft HyperV w wersjach Windows Server 2008 oraz Windows Server 2008 R2, Xen oraz Citrix XenServer w wersjach 5.5 stosowanych przez Zamawiającego. Agent backupu musi wspierać systemy operacyjne typu Windows, Linux, Novell, Unix i Mac OS X stosowane przez Zamawiającego. Wymagania dla mechanizm deduplikacji danych System musi być wyposażony w technologię deduplikacji danych. Deduplikacja musi działać w oparciu o technologię stałej długości bloku, przy czym długość ta zależna jest od wykrytego typu pliku. Niedopuszczalne jest stosowanie mechanizmów deduplikacji o zmiennej długości bloku lub o zawsze stałej długości, niezależnie od typu pliku. Deduplikacja musi działać w oparciu o mechanizm identyfikacji typu pliku i na tej podstawie, dobierać optymalną wielkość bloku, przykładowo: inną dla dokumentu MS Word, inną dla prezentacji MS PowerPoint, inną dla arkusza MS Excel a jeszcze inną dla pliku maszyny wirtualnej VMDK. Oprogramowanie musi mieć wbudowaną bazę różnego typu plików wraz z odpowiadającymi im rozmiarami optymalnych długości bloku. Administrator musi mieć możliwość określenia jakie typy plików będą deduplikowane jaką długością bloku. Funkcjonalność ta ma dawać przynajmniej możliwość zdefiniowania następujących długości bloków w bajtach dla poszczególnych typów plików: 1024, 2048, 4096, 8192, 16384, 32768, 65536. Administrator musi mieć możliwość zdefiniowania (dla każdego z zadań backupu z osobna), czy deduplikacja będzie włączona czy nie oraz czy funkcja ta ma być realizowana na poziomie klienta (agenta) czy po stronie centralnego serwera backupu. Mechanizm deduplikacji musi mieć możliwość operacji na dowolnych danych, w tym minimum pliki, bazy danych, maszyny wirtualne, poczta MS Exchange, MS Sharepoint jak i na każdych innych danych. Mechanizm deduplikacji musi działać przynajmniej na każdym wymienionym dalej systemie operacyjnym klienta (agenta): Windows, Linux, MacOS, FreeBSD, NetBSD, OpenBSD, Solaris. Wymagania dla mechanizmu łańcuchowania D2D2T Oprogramowanie musi być wyposażone w funkcję łańcuchowania backupu DiskToDiskToTape (D2D2T) umożliwiające zdefiniowanie zadania backupu na dysk, które po zakończeniu automatycznie przeniesie dane na taśmę (za pośrednictwem napędu lub biblioteki taśmowej). Administrator musi mieć możliwość zdefiniowania odstępu czasu wyrażonego w minutach, które opóźni moment przenoszenia danych na taśmę w stosunku do momentu zakończenia zadania backupu na dysk. Czas ten musi być definiowany dla każdego zadania backupu. Funkcjonalność łańcuchowania D2D2T musi być możliwa także dla backupów ujętych w harmonogramie. Przy definiowaniu zadania backupu z uaktywnionym łańcuchowaniem D2D2T administrator musi mieć możliwość określenia polityki wykorzystywania taśm (użycie istniejących taśm do końca lub wykorzystanie nowych taśm), określenia retencji dla backupu na taśmie oraz możliwość włączenia szczegółowego raportowania na email o statusie zadania. Administrator musi mieć możliwość zdefiniowania zautomatyzowanego mechanizmu D2D2T dla danych zapisanych na dysku, przy czym wyzwolenie zdarzenia łańcuchowania będzie związane minimum z: wielkością wykorzystywanego miejsca na wybranym zasobie dyskowym z dokładnością do 1MB, ilością pozostałego miejsca na zasobie dyskowym z dokładnością do 1MB. Administrator musi mieć także możliwość zdefiniowania kolejności z jaką dane będą zapisywane na taśmie, minimum jako: od najstarszych do najnowszych lub od najnowszych do najstarszych. Administrator musi mieć możliwość zdefiniowania czy po zakończeniu procesu łańcuchowania D2D2T dane na zasobie dyskowym mają być usunięte czy pozostawione. Szkolenie Szkolenie w wymiarze minimum 4 do 8 godzin dla 3 przyszłych administratorów systemu..

II.4) Wspólny Słownik Zamówień (CPV): 48.80.00.00 - Systemy i serwery informacyjne 48.81.00.00 - Systemy informacyjne 48.82.10.00 - Serwery sieciowe .

SEKCJA III: PROCEDURA

III.1) TRYB UDZIELENIA ZAMÓWIENIA: Przetarg nieograniczony

III.2) INFORMACJE ADMINISTRACYJNE

• Zamówienie dotyczy projektu/programu finansowanego ze środków Unii Europejskiej: nie

SEKCJA IV: UDZIELENIE ZAMÓWIENIA

IV.1) DATA UDZIELENIA ZAMÓWIENIA: 09.07.2013.

IV.2) LICZBA OTRZYMANYCH OFERT: 1.

IV.3) LICZBA ODRZUCONYCH OFERT: 0.

IV.4) NAZWA I ADRES WYKONAWCY, KTÓREMU UDZIELONO ZAMÓWIENIA:

• PASSUS Sp. z o.o., ul. Wiktorska 63, 02-587 Warszawa, kraj/woj. mazowieckie.

IV.5) Szacunkowa wartość zamówienia (bez VAT): 93200,00 PLN.

IV.6) INFORMACJA O CENIE WYBRANEJ OFERTY ORAZ O OFERTACH Z NAJNIŻSZĄ I NAJWYŻSZĄ CENĄ

• Cena wybranej oferty: 70110,00

• Oferta z najniższą ceną: 70110,00 / Oferta z najwyższą ceną: 70110,00

• Waluta: PLN.