Architektura. Upgradované diskové pole musí být modulární, minimálně dvouřadičové pole založené na 12Gbit SAS architektuře. Řešení musí být koncipováno jako HW, SW a FW 100% kompatibilní entita, s blokovým a souborovým přístupem k datům (FC, FCoE, iSCSI, NFS, CIFS současně). Řešení pomocí externích např. NAS „head“ není přípustné. Řešení musí minimálně splňovat stávající funkcionalitu NetApp MetroClusteru. Toto řešení musí poskytovat samotné kontrolery diskového pole (řešení pomocí externího zařízení není přípustné). Řešení musí umožňovat rozšíření storage clusteru až na 4 nody (kontroléry) v každé lokalitě celkem tedy 8x kontrolér. Požadavkem je také to, aby případné další 2 a 2 kontroléry nemusely být stejného typu.
Architektura. Jedná se o třívrstvou architekturu (klient, aplikační server, databáze). V případě mapových podkladů pak lze k datové vrstvě připojit i rastrová data, která jsou v souborovém systému. Pro starší moduly je nutno mít na klientské stanici nainstalován MapGuide ActiveX komponentu, která komunikuje s MapGuide Agentem a ten následně s MapGuide Serverem. Aplikační logika je pak řešena pomocí ColdFusion skriptů. Nově implementované řešení je postaveno na open source technologiích – JAVA a MapSource serverem. Obě technologie zpracovávají vektorová data uložená v Oracle Spatial databázi a rastrová data dostupná z SAN sítě. Pro zobrazení 3D modelu terénu je implementován AutoDesk MAP 3D 2005. Vazby na jiné systémy a aplikace Závisí na: LPIS jako základní registr pracující s geografickou informací je provázán na veškerou funkcionalitu, které vyžaduje prostorovou lokalizaci. LPIS závisí na datech z Meziskladu zpráv o kontrole pro účely stanovení rizikové analýzy. LPIS je integrová na SZR a registr zvířat (v oblasti modulu kontrol ÚKZÚZ. Modul evidence umístění provozoven je skrze webové služby integrován s DMS. “. Poskytuje služby: Registr poskytuje „lokalizační“ funkcionalitu všem ostatním registrům, které to vyžadují. Tuto funkcionalitu poskytuje i příslušným systémům OSS organizací. Současně LPIS poskytuje cca 100 datových služeb, zejména SZIF v rámci procesu přípravy předtisků žádostí o dotace a následných SW kontrol. Prostředí Servery Viz dokumentace. Databáze Databáze LPIS v rámci RAC registrů. Čtení z databáze CODEL. Čtení pomocí databázových linků z RVIN, EPH, IZR, SZR, CRVE. Sumární přehled vazeb systému Typ vazby Počet DB Link Konzument 32 DB Link Zdroj 31 DB Query (SELECT) Konzument 1 ESB / EPO Konzument 3 ESB / EPO Konzument - VVD 2 ESB / EPO Zdroj 6 ESB Konzument 15 ESB Konzument - VVD 8 ESB Zdroj 42 ESB Zdroj - VVD 4 Celkem 144 Zkratka VVD znamená „Ve volání jsou data“. Odlišení služeb typu VVD se uvádí proto, že v dotaze jsou zasílána data, která zdrojový systém přijímá a následně s nimi pracuje. Běžná služba v dotazu obsahuje parametry a zdrojový systém vrací data dle parametrů z dotazu. Název služby Provoz testovacího prostředí aplikace LPIS Prostředí TESTOVACÍ Cílová skupina Pracovníci Objednatele, pracovníci OSS resortu Objednatele, celní správa, farmáři Zkrácený popis Registru Registr půdy LPIS je centrálním registrem pro agendy související se zákonem č.252/1997Sb., ve znění pozdějších předpisů, a dalšími obecně závaznými právními předpisy včetně př...
Architektura a) výkon a podpora v rámci tvorby architektonické schopnosti (zavedení metody ADM, rámec, principy, pravidla a standardy),
Architektura. Plná integrace s dodávaným síťovým managementem (zařízení není nutno zadávat zařízení vícekrát, informace jsou automaticky sdíleny) ANO ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxxxx/xxxxxx_xxxxxxx/xxxx/x_xx_xx_xx_xxx_xxxxxx_xxxxxx.xxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxxxxxXxxxxxXXXxxxxxxxxx ANO Vmware; xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxxxxxXxxxxxXXXx ANO/ 500 Viz Priloha_kompletni_konfigurace_dodavky_v1.xlsx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxxxxxXxxxxxXXXxxxxxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxx/xx_xx_xxxxxx_xxxx.xxxx#XxxxxxXxxxxxxxxxxXxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxx/xxxx/xx_xxxxx_xxxxx.xxxx#XxxxxxxxxxxxxxXxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxx/xxxx/xx_xxxxx_xxxxx.xxxx#XxxxxxxxxxxxxXxxxxxXxxxxxxxxx://xxx.xxxxxxxxxxxxxxx.xxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxxxx/xxxxxx_xxxxxxx/xxxx/xx_xx_xx_xx_xxxxxxx.xxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxxxx/xxxx/x_xx_xxxxxxx_xxxxxxxx.xxxx Klient - Server ANO Požadovaný formát zařízení VMware či HW Appliance ANO Požadovaný počet spravovaných zařízení 500 Plnohodnotná klientská část podporovaná na operačních systémech Linux, Windows i OS X ANO Plnohodnotný přístup přes HTML pomocí webového prohlížeče (minimálně Edge, Firefox, Chrome) ANO Víceúrovňová práva přístupu, podpora paralelní práce více uživatelů ANO Podpora autentizace pomocí LDAP, Radius ANO RBAC (rozdílní uživatelé mají práva k rozdílným prvkům a rozdílným funkcionalitám) ANO Konfigurace, monitoring i reporting systému přes HTTPs rozhraní ve standardním webovém prohlížeči (minimálně Edge, Firefox, Chrome) ANO Možnost systém rozšířit o služby agentového skenování (assessmentu) pouze aplikací licenčního klíče ANO Systém musí být schopen výměny informací s dalšími systémy (otevřené a dokumentované API). API musí poskytnout minimálně následující funkce: ANO 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1-3 1 1 1 1 1 1 1 1 1...
Architektura. Řešení IP telefonního systému umožní nasazení řešení komunikační infrastruktury s centralizovaným zpracováním hovorů v prostředí více lokalit, propojených IP WAN sítí CamelNet s využitím prostupů do veřejné telefonní sítě. Řešení musí umožnit nasazení centralizovaného modelu pro celé prostředí zadavatele formou jediného společného aplikačního clusteru, zajišťujícího: • jednotnou sadu služeb dostupnou uživatelům v rámci celého prostředí zadavatele; • přenositelnost čísla a uživatelských služeb v rámci prostředí zadavatele; • centralizovanou správu systému v rámci celého prostředí zadavatele;
Architektura. Obr 2 . GUI – obrazovky
Architektura. Vzhledem k tomu, že je pravděpodobné, že se aplikace bude využívat ve větší míře než doposud, a je požadována dlouhodobá udržitelnost, musí mít některé architektonické charakteristiky, které zajistí, že ji bude možné přizpůsobit změnám zátěže, změnám HW prostředí i podkladových operačních systémů, SW výbavy a změnám na úrovni integrovaných systémů. Aplikace musí splňovat tyto požadavky: Uživatelská i serverová část aplikace je spustitelná minimálně na OS Windows a Linux. Uživatelské webové rozhraní, které lze spustit v běžně používaných webových prohlížečích Chrome, Firefox MS Edge v aktuálních verzích operačních systémů Microsoft Windows, MacOS a Linux. Centrální konfigurace funkcionalit je dostupná z uživatelského rozhraní. Serverová aplikační část disponuje aplikačním rozhraním REST nebo SOAP. Správce má možnost zobrazit dokumentaci aplikačního rozhraní přímo z uživatelského rozhraní. Serverovou aplikační část lze spouštět ve více instancích a na více serverech a lze tak přizpůsobovat výkon aplikace. Zátěž mezi těmito instancemi je rovnoměrně rozdělována přímo aplikací. Systémové záznamy o běhu aplikace jsou dostupné administrátorovi z uživatelského rozhraní. Aplikace umí zobrazit systémové statistické informace o svém běhu. Veškerý spravovaný obsah je fulltextově dohledatelný. Aplikace podporuje technologie autentizace uživatele (MS AD a Azure ID) a splňuje požadavky na kybernetickou bezpečnost (ochrana před neoprávněnou změnou a zneužitím informací). Aplikace podporuje nativně nebo přes specifikované rozhraní integraci na cloud technologie MS O365 v oblasti ukládání a synchronizace obsahu a správy uživatelů. Aplikace musí být připravena na budoucí požadavek více faktorové autentizace. Aplikace je spustitelná v plně virtualizovaném prostředí. Aplikace umožnuje integraci se systémem správy identit, který je využíván na ÚMČ Praha 2 (IDM systém, MS AD, Azure ID).
Architektura. Servery a pole musí být samostatné jednotky propojené technologií FC (Fibre Channel). Použitá technologie je standardu 8 Gbps Fibre Channel - FC. Ano Konektivita serverů a polí musí být realizována redundantně prostřednictvím FC switchů, které musí být součástí dodávky. Součástí dodávky jesou dva FC switche, každý s 16 zalicencovanými a osazenými porty o rychlosti alespoň 8 Gb. Ano Veškeré patchcordy nezbytné pro zajištění propojení SAN infrastruktury musí být součástí dodávky. Jsou součástí Ano Součástí dodávky musí být veškeré nezbytné optické patchcordy pro zajištění Ethernet konektivity serverů i pole. Patchcordy musí být standardu 10GBASE-SR s konektory LC na jednom konci. Jsou součástí Ano Součástí dodávky musí být příslušný počet optických transceiverů pro osazení síťových karet v dodaném HW. Optický switch v místě instalace je již osazen (10GBASE-SR SFP+ LC). Jsou součástí Ano SAN infrastruktura musí být postavena na 8 Gb nebo 16 Gb FC technologii. SAN infrastruktura je postavena 8GBps technologii Ano Nejméně dva front-end servery, které disková pole zpřístupní jako blokové zařízení linuxovým OS přes multipath. Veškeré požadavky na servery včetně výkonnostních musí být splněny všemi front-end servery. Předmětem nabídky jsou 2 Front-End servery Supermicro při splnění požadovaných podmínek Ano Každý server musí mít minimálně 24 fyzických procesorových jader se sdílenou pamětí v architektuře x86_64. Minimální výkon celého uzlu měřený nástrojem Spec2006 ve variantě FP, rate, baseline musí být alespoň 640 bodů. Splněno Ano Každý server musí mít alespoň 256 GB RAM ECC min. DDR4. Každý server je konfigurován s 8x DDR4 32GB DIMM 2400MHz Ano Každý server musí být osazen dvěma systémovými disky s kapacitou alespoň 120 GB SAS každý (min. 10k rpm nebo SSD), s možností sestavení v mirroru. Každý server je konfigurván s 2x 120GB SSD s možností sestavení v mirroru Ano Každý server musí mít alespoň dva porty 10 Gb s optickým rozhraním Ethernet 10GBASE-SR a možnost bootovat přes PXE buď z těchto optických portů, nebo z dalšího Ethernet portu o kapacitě min. 1 Gbps. Splněno Ano Každý server musí mít min. 2x FibreChannel rozhraní pro připojení do SAN infrastruktury o celkové rychlosti alespoň 16 Gb/s (tj. alespoň 2x 8 Gb FC) realizované dvěma nezávislými HBA kartami. Splněno, realizováno dvěma nezávislými HBA o rychlosti 2x 8Gbps, tj. 16GBps Ano Servery musí mít duální napájení. Zdroje i disky musí být vyměnitelné za chodu. Splněno, duálním zdrojem Ano Server musí um...
Architektura. Systém předávání zpráv TACHOnet se skládá z následujících částí:
Architektura. 1.1. Propoje serverů zadavatele a dodávaných polí musí být realizované redundantně, propojení musí být realizováno tak, aby výpadek jakékoliv propojovací cesty neznamenal výpadek celého systému.