Příloha č. 2 Zadávací dokumentace Technická specifikace

Transkript

1 Příloha č. 2 Zadávací dokumentace Technická specifikace Celý systém musí být dodán po stránce hardwarové i softwarové vč. montáže do připraveného datacentra a to vč. systémové záruky funkcionality každé z uvedených hardwarových si softwarových komponent. Součástí dodávky je i zaškolení pracovníků objednatele a předání sofwarových řešení tak, aby byl umožněn další vývoj řešení na straně odběratele. 1. Hardware testovací: 4 ks serverů v následující konfiguraci: 3U case - 16 HDD hotswap SATA 1 DualSocket Intel motherboard 1 LAN IPMI (remote KVM) 1 1GBits port 2 10GBits port 2 ports card 1 RAM 256 HDD 2TB SATA GB SSD SATA 4 HBA (disk non raid controller) 1 CPU 8 cores s výkonem min bodů dle CPU benchmark (PassMark sw) 2 4 ks testovací řídící server v následující konfiguraci: 1U case 1 SingleSocket Intel motherboard 1 LAN IPMI (remote KVM) 1 1GBits port 2 RAM 64 HDD 500GB SATA 3 CPU 8 cores s výkonem min bodů dle CPU benchmark (PassMark sw) 1 Aktivní síťové prvky v následující konfiguraci: 10GBits Switch 2 48Gbits Gigabit Management Switch 2

2 2. Software vývojový: Pro účely dalšího vývoje dodané aplikace požadujeme: pořízení vývojových nástrojů pro vývoj a úpravu aplikací od výrobce Microsoft developerské verze nejpoužívanějších kancelářských balíků MS-OFFICE, napojení na aktuální Microsoft Sky-Drive, integrace NET atd., vývojové prostředky pro automatické ovládání Windows (active directory, atd). a to jakožto multilicence pro tým min. 3 vývojářů. Dále požadujeme vývojové prostředí pro tvorbu PHP a šifrování výsledných PHP aplikací. Dodávka vývojových aplikací musí být proporcionální k projektu jako celku ve smyslu navázání na dodané dílo vlastními programátory pomocí uvedených softwarových vývojových nástrojů. 3. Hardware hlavní cloud: Celkový rámcový výkon dodaného harware musí být minimálně následující: Celkový počet CPU CORE: 640 RAM: 8TB Celková disková kapacita: min. 864 TB Rychlost zápisu na disk/storage: 14 Gbit RAM disk pro velké databáze Rychlost komunikace mezi servery / disky: 10 Gbits a 40Gbits (min. část. komunikace technologií infiniband kompatibilní s Linux Kernel) Ekonomická doba života min.: 4 roky Záruka na jednotlivé komponenty: min. 4 roky Celková systémová záruka řešení: 36 měsíců Hlavní cloud musí sestávat z uvedených částí: hypervisor serverů kompatibilních s AMD technologií v následující konfiguraci: 3U case - 16 HDD hotswap SATA DualSocket motherboard LAN IPMI (remote KVM) 1GBits port 10GBits port RAM 512 GB HDD 2TB SATA 1 240GB SSD SATA 4 ks HBA (disk non raid controller) CPU 12 cores s výkonem min bodů dle CPU benchmark (PassMark sw)

3 10 ks hypervisor serverů kompatibilních s Intel technologií v následující konfiguraci: 3U case - 16 HDD hotswap SATA DualSocket motherboard LAN IPMI (remote KVM) 1GBits port 10GBits port 2 ports card RAM 256 GB HDD 2TB SATA 1 240GB SSD SATA 4 ks HBA (disk non raid controller) 1ks CPU 8 cores s výkonem min bodů dle CPU benchmark (PassMark sw) hypervisor speed disk serverů kompatibilních s AMD technologií v následující konfiguraci: 3U case - 16 HDD hotswap SATA DualSocket motherboard LAN IPMI (remote KVM) 1GBits port 10GBits port RAM HDD 2TB SATA 480GB SSD SATA 240GB SSD SATA HBA (disk non raid controller) CPU 12 cores s výkonem min bodů dle CPU benchmark (PassMark sw) 512 GB 6 ks 6 ks 4 ks 8 ks hypervisor speed disk serverů kompatibilních s Intel technologií v následující konfiguraci: 3U case - 16 HDD hotswap SATA DualSocket motherboard LAN IPMI (remote KVM) 1GBits port 10GBits port 2 ports card RAM 256 GB HDD 2TB SATA 1 240GB SSD SATA 4 ks 480GB SSD SATA 6 ks

4 HBA (disk non raid controller) CPU 8 cores s výkonem min bodů dle CPU benchmark (PassMark sw) 1ks objektový storage serverů kompatibilních s Intel technologií v následující konfiguraci: 4U case - 36 HDD hotswap SATA SingleSocket motherboard LAN IPMI (remote KVM) 1GBits port 4 ks RAM 64 GB HDD 3TB SATA 7 HBA (disk non raid controller) CPU 4 cores s výkonem min bodů dle CPU benchmark (PassMark sw) řídící server kompatibilních s Intel technologií v následující konfiguraci: 1U case SingleSocket motherboard LAN IPMI (remote KVM) 1GBits port RAM HDD 500GB SATA CPU 4 cores s výkonem min bodů dle CPU benchmark (PassMark sw) 32 GB 3 ks 4. Hardware ostatní: Ostatní hardware musí pokrývat veškeré hardwarové vybavení nutné pro provoz testovacích serverů a hlavního cloudu a musí obsahovat minimálně následující komponenty: Aktivní prvky (switche): 10 GBits port managed switch 24 port: 4 ks 1 GBits port managed switch 48 port: 8 ks Specifikace a minimální výkonové požadavky switchů: - min současně fungujících VLAN - SSH administrace / nebo API (možnost ovládat switch

5 přes skript) - SNMP monitoring - JUMBO frames - varianta openflow podpora Datové rozvaděče: 42U RACK, 100 cm hloubka, pevná konstrukce: 4 ks Řídící server: server 1U 1x LGA1155, ic202, 4x DDR3 ECC, 4x SATA HS (3,5"), 350W, IPMI CPU (4-core) s výkonem min bodů dle CPU benchmark (PassMark sw) 1TB HDD 2 kusy, 32 GB RAM Nepřerušitelný napájecí zdroj: On-line UPS modulární 16kW/20kVA Součástí dodávky musí být i veškerá kabeláž a propojovací komponenty, díly pro montáže do datových rozvaděčů, kompletní montáž testovacího harware, hlavního cloudu i ostatního hardware. 5. Software jednotné přístupové rozhraní: 5.1 základní požadavky základní funkce požadovaného systému Popis: systém bude muset na základě příkazů z ostatních částí systému vytvářet a konfigurovat virtuální stroje a zajišťovat jejich chod. systém tedy musí sloužit jako nejnižší vrstva cloudového systému. Musí zajišťovat integraci s ostatními vizualizačními technologiemi. systém se musí umět vyhnout komplexním systémům třetích stran (OpenStack, CloudStack,...) Systém musí být jednoduchý pro dosažení požadavku snažší údržby a dalšího rozvoje. Systém musí mít API pro komunikaci s ostatními částmi systému. Systém řídící musí být plně redundantní napříč lokalitami podpora hypervizoru Popis: systém musí umožnit provoz virtuálních stroju na hypervizorech XEN a KVM.

6 Skupiny hypervizoru Popis: systém musí umožnit pro vyšší vrstvy systému abstrahovat od jednotlivých výpočetních nodů. Dostupné prostředky musí umět nabízet ve formě skupin těchto výpočetních nodů. Skupiny budou tvořeny nody vzájemně kompatibilními za účelem provádění vyvažování výpočetního výkonu. Systém musí pracovat tak, že vyšší vrstvy nemusí vědet, kde přesně virtuální stroj běží. Za zajištení jeho bezproblémového chodu musí odpovídat backend. 5.2 požadované vlastnosti systému směrem k datovým úložištím Připojení disků Popis: systém musí umožnit připojení virtuálních disků k VM. Virtuální disky jsou definované typem úložiště a svou velikostí. Datová úložište: existuje více různých druhu úložišť. Mohou se lišit svou rychlostí, maximální kapacitou a cenou. Pro různá použití jsou vhodné různé typy úložišť, a proto je nutné nechat výběr typu na klientovi. V tomto smyslu musí být backend univerzální. Lokální datové úložište Popis: systém musí umožnit ukládat virtuální disky lokálně na výpočetních nodech. Důvod funkce: Jedná se o nejlevnější a nejjednodušší způsob uložení dat. Ideální pro dočasné prostory a testování. Sdílené datové úložište Popis: systém musí umožnit ukládat virtuální disky na úložiště sdílené mezi alespoň dvěma výpočetními nody. Důvod funkce: Dostupnost stejných dat na více nodech zajistí kontinuitu provozu v případě selhání jednoho nodu. Clusterové úložište Popis: systém musí umožnit ukládat virtuální disky do clusterového úložište (CEPH, GlusterFS, ZFS, DRBD, LVM a další obvyklé) Důvod funkce: Umožní oddělit výpočetní nody od úložiště a dále rozšíří možnosti live migrace. Úložište obrazu cd a disku systém musí umožnit práci s obrazy cd a disku uložených v externím NFS úložišti.

7 Důvod funkce: Templaty disku a obrazy cd se běžně používají při instalaci a správě virtuálních strojů a velmi ji zjednodušují, proto musí být tato funkce součástí projektu. Změna velikosti disku Popis: systém musí umožnit měnit velikost již vytvořených disků. Důvod funkce: V průběhu používání virtuálního stroje je běžný problém nedostatku nebo naopak přebytku prostoru. Snapshoty Popis: systém musí umožnit vytvářet snapshoty disku virtuálních strojů a jejich obnovu. Důvod funkce: Snapshoty umožňují rychlé uložení stavu virtuálního počítače a zpětný návrat. Slouží k rychlé záloze před pokusem o provedení rizikové operace (například upgrade systému). 5.3 požadované vlastnosti systému směrem k síťové vrstvě Připojení do sítě Popis: systém musí umožnit připojení virtuálních počítačů do sítí definovaných svým číslem VLAN a přidělenou IPv4 adresou. Důvod funkce: Sítová konektivita je základní službou. Sítí muže být více a různých druhů (privátní, veřejné, rychlostně omezené atd. ). Zamezení použití nepřidělené ip adresy Popis: Přístup virtuálního počítače do sítě s cizí nebo nepřidělenou adresou nebude umožněn. Důvod funkce: Zabránění nežádoucímu ovlivnění zbytku infrastruktury v případě pokusu o krádež identity nebo chybné konfiguraci stroje. IPv6 Popis: Podpora pro IPv6 Důvod funkce: Umožnit přidělování a ochranu IPv6 adres stejným způsobem jako u IPv4. DHCP Popis: systém bude přidělovat ip adresy pomocí DHCP. Důvod funkce: Usnadní konfiguraci virtuálních strojů.

8 5.4 požadované vlastnosti systému směrem ke správě virtuálních strojů Vytvoření, smazání a změna parametru Popis: systém musí umožnit vytvářet, mazat a upravovat parametry virtuálních strojů. Minimální povinné konfigurovatelné parametry jsou následující: Počet procesorů - ke kolika procesorům bude mít VM přístup RAM - kolik paměti RAM bude pro VM dostupné připojený obraz CD - jaký obraz disku bude použit pro simulaci CD mechaniky připojené disky viz. kapitola 1.2 připojené sítě viz. kapitola 1.3 Skupina výpočetních nodů, ve které VM poběží, musí být specifikována při jeho vytvoření a dále už se nebude měnit. Vnc konzole Popis: systém musí umožnit připojení ke grafické konzoli na virtuálním stroji pres protokol VNC. Důvod funkce: Konzole se typicky používá v případě problému s běžným administračním prostředkem (typicky ssh nebo rdp). Nezávisí na OS uvnitř virtuálního stroje a tudíž se od ní nelze konfigurační chybou odříznout. Změna parametru VM za běhu systému Popis: systém musí umožnit změnu parametru virtuálního stroje bez nutnosti tento virtuální stroj restartovat (pouze tam, kde to umožňuje použitý hypervisor). Důvod funkce: Umožní přidat rychlejší disk nebo další procesor při neočekávaném náporu na virtuální stroj aniž by došlo k přerušení dodávané služby. Offline migrace Popis: systém musí umožnit offline (při vypnutém VM) migraci na jiný výpočetní node. Důvod funkce: Offline migrace je proveditelná i bez sdíleného úložiště. Je důležitá pro vyvažování obsazeného výkonu a provádění údržby na výpočetních nodech. Live migrace Popis: systém musí umožnit online (VM muže být zapnutý) migraci na jiný výpočetní node. Důvod funkce: Live migrace vyžaduje sdílené úložiště. Je ale mnohem praktičtější, protože nevyžaduje žádné přerušení služby. Vyvažování využitého výkonu

9 Popis: systém musí umět automaticky měnit umístění VM na výpočetních nodech tak, aby bylo maximalizováno využití hardware. Důvod funkce: Parametry (i běžících) virtuálních strojů se mohou měnit a s tím může přijít přetížení nebo nevyužití jednotlivých výpočetních nodů. Backend musí zajistit průběžné vyvažování výkonu. 5.5 API Vytvoření, smazání a změna parametru VM Popis: API musí umožnit vytvářet, mazat a měnit parametry virtuálních strojů. Parametry virtuálních strojů jsou popsány výše. Aktuální stav virtuálního stroje Popis: API musí umět pro každý VM poskytnout informace o jeho aktuálním stavu (zapnuto, vypnuto) a umožní ho změnit (zapnout, vypnout, restartovat). Důvod funkce: Stav VM se může měnit bez zásahu z API (softwarové vypnutí stroje). Dostupnost Popis: API musí být po síti dostupné pro zbytek systému. Důvod funkce: Ostatní části systému nemusí být na stejném serveru. Informace o dostupných skupinách výpočetních nodů Popis: API musí umožnit ostatním částem systému informovat o dostupných skupinách výpočetních nodů. Důvod funkce: Ostatní části systému budou používat API pro získání seznamu aktuálne dostupných výpočetních prostředků Informace o aktuálním vytížení skupin výpočetních nodů Popis: API musí umožnit ostatním částem systému informovat o aktuálním zatížení jednotlivých skupin a dostupných volných prostředcích (RAM, CPU load atd.) Důvod funkce: Ostatní části systému budou používat API pro získání aktuálního stavu výpočetních prostředků. Informace o dostupných úložištích pro každou skupinu nodu Popis: API musí ostatní části systému informovat o úložištích, která jsou k dispozici každé skupině výpočetních nodů. Důvod funkce: Konzument API se musí dozvědět, jaká jsou platná úložiště pro vytváření nových disku.

10 Informace o volném místě na úložištích Popis: API musí ostatní části systému informovat, kolik volného prostoru je k dispozici na jednotlivých úložištích (tedy jak maximálně velký virtuální disk lze na nich vytvořit). Důvod funkce: Některá úložiště mohou být přechodně přetížena a nemusí mít kapacitu pro vytvoření nového disku. Konzument API se to tímto způsobem musí dozvědět. Informace potřebné pro připojení k VNC konzoli Popis: API musí pro každý VM poskytnout informace potřebné k připojení k VNC konzoli (min. IP adresa, port, heslo) Důvod funkce: Díky přesouvání VM v systému se VNC endpoint může měnit. API musí poskytnout aktuální informace zbytku systému. 5.6 grafická podoba - požadavky Popis: grafická podoba požadovaného systému musí být jednoznačná, bez zdvojených cest uživatelů, uživatelsky příjemná a intuitivní. Grafika musí být graficky i ergonomicky na úrovni největších světových konkurentů. Barevné naladění webu musí být dle nejmodernějších trendů. Část viditelná pro uživatele musí být vytvořena systémem adaptive design. Grafická podoba musí počítat s templatizovatelností/skinovatelností (zákazníkem může být provozovatel Cloudu, který chce využít náš cloud pod svojí hlavičkou) 5.7 Základní provozní servery, které systém musí obsahovat: Autorizační vnitrokomunikační server: Popis: Systém musí obsahovat server, ve kterém jsou uloženy komunikační klíče jednotlivých serverů (např. ssh) Funkce: Autorizačního serveru se každý server při přijetí requestu ptá, jestli daný server má právo s kontaktovaným serverem komunikovat. Centrální uživatelský server (práva, nastavení): Popis: Zde jsou uloženi všichni existující uživatelé systému, obsahuje informace o objednaných službách, základních limitech uživatelů (aktualizuje billing server - kredit) Funkce: Jakýkoliv request na rozšíření služby (např. založení nové služby) - před ním je proveden dotaz na tento server. Tento server zodpoví GUI, jestli je možné daný požadavek vyřídit či nikoliv. Server s GUI komunikuje na úrovni vytvoření requestu a potvrzení splnění reqestu.

11 Billing server: Popis: Do billing serveru vysílají jednotlivé servery informaci, jak byli na nich běžící VPS využity (např. load) Funkce: Kredit uživatelů je uložen na tomto serveru včetně podrobné historie: Od kdy do kdy a co daný uživatel využívá (SaaS, PaaS, atd.). Billing serveru se centrální uživatelský server ptá, zdali na něj přijatý request je z hlediska finančních prostředků uživatele realizovatelný. Dále server Generuje faktury, notifikuje klienty o stavu kreditu atd. 5.8 Test service: Systém musí uživatelům umožnit otestovat služby v následujících konfiguracích: Levný cloud: Single server s výkonem pro provoz 20x VPS, vlastní diskové úložiště, single RAM konfigurace: 2x CPU XEON E GB RAM 8x 2TB HDD OS DEBIAN Filesystem ZFS (super na snapshoty a clonování) XEN virtualizace Nejrychlejší možné diskové úložistě Redundantní cloud: Dva servery s výkonem pro provoz 20x VPS, každý vlastní diskové úložiště, single RAM, konfigurace: 2x CPU XEON E GB RAM 8x 3TB HDD OS DEBIAN Filesystem ZFS (super na snapshoty a clonování) XEN virtualizace Servery mezi sebou propojeny prostřednictvím 10Gbits / Infiniband 40Gbits a křížově je prováděn zfs snapshot sync mezi jednotlivými servery, každých 5 minut. 5.9 konfigrace hlavního cloudu musí být následující: záložní hypervizory, s výkonem pro provoz cca 20x VPS, každý 10GBits konektivita k diskovému poli, 2x 1Gbits konektivita LAN (administrace / provoz)

12 o o 2x CPU XEON E GB RAM OS DEBIAN Filesystem na ZFS, LVM, CEPH, DRBD XEN virtualizace / KVM virtualizace Normální diskové úložistě (rychlost min. 300Mb/sec) Livemigrace, možnost přepojení na jiný volnější hypervizor v rámci kostky Propojena disková síť 10GBits switch Propojena vnitrokomunikace mezi servery prostřednictvím 1GBits switche systém musí dále obsahovat: - Ovladání mikrotik FW / VLAN prostřednictvím Mikrotik API - webvnc řešení, nutno také implementovat možnost použití ultravnc app - ovládání ZFS (zfs příkaz) - ovládání XM nebo xen-api - ovladání CEPH (RDB zakládání, rušení a ostatní běžné funkce) - ovládání LVM (objektová storage) - backupy (využití open-source zálohovací systém, snapshoty) - sledování stavu serverů / systému 6. Software Cloud Data Storage: Požadavky na systém: Datové úložiště musí volitelně umožňovat šifrování veškerých dat tak, aby k nim neměla přístup třetí strana ani poskytovatel služby. Funkce: ZFS: LVM: CEPH Zakládání LV Mazání LV Změnu velikosti LV Řízení snapshotů (zálohové, uživatelské, replikační) Zakládání LV Mazání LV Změnu velikosti LV Řízení snapshotů Zakládání LV Mazání LV Změnu velikosti LV Řízení snapshotů (zálohové, uživatelské, replikační)

13 DRBD Zakládání LV Mazání LV Změnu velikosti LV Řízení snapshotů (zálohové, uživatelské, replikační) NFS (linux platforma) Objektová storage kompletní management SAMBA (Windows platforma) Objektová storage kompletní management Z hlediska šifrování: Ovládání přes API: Truecrypt Bitlocker Dmcrypt Luks Dodavatel je povinen dodat kompletní dokumentaci k napsanému API a přístup do vlastního testovacího prostředí. 7. Software virtual PC: Požadavky na systém: řešení produktu "virtual PC" integrací open-source produktů a/nebo využití běžných produktů zejména Microsoft. Důraz na jednoduchost použití. Systém musí umožnit rychlé zakládání virtual PC jednotlivými uživateli s připravenými nástroji a následující funkcionalitou: Funkce: Oblast Microsoft Windows Servers: Vytvoření tzv. daemona musí pro jednotlivé Node umět následující funkce: - Zakládání uživatelů - Mazání uživatelů - Editace uživatelů - Tvorba skupin uživatelů - Nastavování prostředí uživatelů (výkon, paměť, disková quota) - Hard kill uživatele - Ovládání konfigurace Remote App - Přidávání a odebírání aplikaci v silent režimu pro jednotlivé uživatele Preferujeme variantu bez nutnosti centrálního active directory. Konfiguraci serverů požadujeme prostřednictvím GPO omezujícího nastavení a dosažení oddělení více skupin v rámci serveru.

14 Požadujeme podporu Windows 2008 R2 a Windows 2012 R2. Přistup prostřednictvím Microsoft Remote Desktop. Oblast OS Linux: Vytvoření tzv. daemona musí pro jednotlivé Node umět následující funkce: - Zakládání uživatelů - Mazání uživatelů - Editace uživatelů - Tvorba skupin uživatelů - Nastavování prostředí uživatelů (výkon, paměť, disková quota) - Hard kill uživatele - Ovládání konfigurace X Windows a aplikací Systém musí umět pracovat bez nutnosti LDAP. Požadujeme podporu OS Debian Jessie. Přistup prostřednictvím VNC nebo X windows prostřednictvím SSH tunelů. 8. Software cloud monitoring: Požadavky na systém: Řešení produktu "cloud monitoring" - monitoring / zabezpečení min. na úrovni každého virtuálního serveru, Cílem je poskytování kvalitního řešení, tedy řešení, které umí monitorovat instalovaná zákaznická řešení a on-line reportovat jejich výpadky pomocí u a GSM (sms). Je třeba také nabídnout víceúrovňový monitoring v dnešní době téměř nutnost pro dobrou práci dealerské sítě projektu. Je třeba, aby systém umožňoval analýzu a grafování. Funkce: Vytvoření vlastního monitorovacího nástroje nebo rozvoj open-source existujícího nástroje (zabbix/nagios): Systém musí umět vytvořit tzv. daemona pro jednotlivé Node. Musí obsahovat následující funkce z hlediska VPS: - Definovat v systému nové VPS o Nutné prostřednictvím síťového backendu komunikovat propustnost - Sledovat hodnoty z VPS poskytující informace o komplexním zatížení a využití prostředků: o Procesor o Paměťi o IO operace HDD o Síťový provoz - Definovat dle přání uživatele hodnoty: Uživatel bude mít možnost si nadefinovat co si přeje sledovat, v jakém rozsahu a jak často. Dále je nutné mít možnost vyhodnocování změn. - Notifikovat uživatele dle přání vzniku událostí: o Podpora odesílání SMS do SMS centra mobilního operátora o Podpora odesílání ů o Podpora tel. zavolání o Podpora zavolání a řešení najatou technickou podporou (managed cloud services)

15 - Billing notifikačních zpráv (cena SMS) - Automatické reagování dle nadefinovaných skriptů na konkrétní události - Grafování a předpověď využití prostředků - Výstupy implementace kibana + elasticsearch - Archivace a její billing Požadavky na cloudový monitoring IaaS (externí nezávislý monitoring): o Stav hardware na úrovní IPMI protokolu o Stav disků o Zátěž sítě o Vytížení procesorů o Odchylky (např. vznik nadměrného počtů VLAN, load sítě, disková zátěž atd.) o Grafování získávaných hodnot o Monitoring switchů a ostatních aktivních prvků (teploměry serverů, disků, procesorů) 9. Software sada cloud uživatelských aplikací: Požadavky na systém: Pro cloudové řešení musí být vytvořen systém, který umožní spustit on-line všechny běžné softwarové aplikace. Lze předpokládat, že statisticky na Cloudu poběží stejné aplikace, jaké běžně uživatelé používají - Microsoft Office spolu s dalšími užívanými aplikacemi: alternativní kancelářský balík Libre Office atd. Systém musí umožňovat v jedné nebo více nabídnutých aplikacích, se zachováním userfriendly objednávky služby: - možnost editace dokumentů přes http (web office) - možnost připojit externí kamery a spravovat je (zoneminder cloud) - herní servery technologie minecraft (instance serverů technologie minecraft pro hráče, viz. např. - synchronizace dat virtuálního PC a lokálních úložišť (unifikace virtuální kanceláře) - PDF reader, PDF konverter online - příprava pro provoz účetních software a informačních firemních systémů (např. Abra, MONEY, Pohoda atd.) - hostovaný clowd typu owncloud - joomla / modx / drupal cloud - vzdálená vpn, maskovaná ip adresa - poštovní server

16 - modul uživatelského CRM (s možností otevřeného vývoje do budoucnosti) - jabber server - VOIP server - implementace typu REDMINE deployment Součástí nabídky musí být soubor screen-shots popisující nabízené řešení.