1. Inici
  2. Estandards
  3. Per la nomenclatura de les infraestructures TI

    Per la nomenclatura de les infraestructures TI

Classificació de l'estàndard TI GENERAL  (35.020)
Codi de l'estàndard 35.020.02
Versió 1.0
Data última actualització 03/05/2018
Responsable Unitat d’Arquitectura Corporativa, CPD i SI – Àrea de Solucions TIC
Llicència

Part 1: Abast

Aquest estàndard fa referència a la nomenclatura de servidors, noms DNS associats a adreces IP, instàncies d’aplicacions, sistemes de fitxers i usuaris tècnics. Es d’obligat compliment a les instal·lacions dels serveis TIC de CTTI.

No aplica a la infraestructura existent (de Lot2 i altres CPDs departamentals). En els projectes de transformació de CPD s’haurà d’avaluar la viabilitat d’implantar-la.

Part 2: Referències

No aplica

Part 3: Termes i definicions

No aplica

Part 4: Identificació servidors pertanyents a un servei

  1. S’ha d’assignar un codi únic de 8 dígits exactes al nom de servidor. Aquest codi haurà de ser biunívoc, i designarà el sistema operatiu que corre sobre el mateix, el servei al que pertany, la tipologia del servidor, l’entorn i un índex. Aquests elements de codificació es distribuiran de la següent manera:

    Imatge 1

    On:

    • Sistema Operatiu. Correspon al codi de sistema operatiu segons la classificació de l’apartat Sistema Operatiu

    • Servei. Correspon al codi de servei descrit a l’apartat Servei

    • Tipologia. Aquest codi, ha de ser definit i inventariat de forma prèvia. En el cas dels projectes SAP, per exemple, serà el corresponent als dos primers dígits del ‘SID SAP’ que s’allotja al servidor. En d’altres casos el primer caràcter cal identificar-lo segons l’apartat Tipus de programari i el segon caràcter segons la taula Model de programari

    • Entorn. Correspon al codi d’entorn mencionat al apartat Entorn

    • Índex. Correspon a un dígit alfanumèric 0-9/a-z controlat pel proveïdor d’infraestructura, en relació a la sèrie de servidors que corresponen a una tipologia d’un servei.

      En el cas de servidors VMWare i Windows, aquest codi pot ser de dos digits.

      NOTA: Alguns sistemes UNIX tenen una limitació de hostname de 8 dígits, és per això que a servidors UNIX/Linux es farà servir únicament un dígit per a aquest camp.

    Exemple:

    Per a un servidor (el primer de la sèrie), que pertanyi al servei ‘G@udí, amb sistema operatiu Windows, pel qual es faci servir la tipologia (específicament definida per a cada servei) ‘wi’ per als servidors web IIS, ubicat a l’entorn de producció, tindrem el següent nom:

    Imatge 2

Part 5: Identificació servidors pertanyents a infraestructures de virtualització

  1. S’ha d’assignar un codi únic de 9 dígits exactes al nom de servidor. Aquest codi haurà de ser biunívoc, i designarà el sistema operatiu que corre sobre el mateix, el servei al que pertany, la tipologia del servidor, l’entorn i un índex. Aquests elements de codificació es distribuiran de la següent manera:

    Imatge 3

    On:

    • Sistema Operatiu. Correspon al codi de sistema operatiu segons la classificació de l’apartat Sistema Operatiu

    • Codi IVI. El codi IVI denota ‘Infraestructura de Virtualització’

    • Tipologia. Correspon al tipus de infraestructura de virtualització que es fa servir. P.e. HA (Host AIX)

    • Entorn. Correspon al codi d’entorn mencionat al apartat Entorn

    • Índex. Correspon a un dígit alfanumèric 0-9/a-z controlat pel proveïdor d’infraestructura, en relació a la sèrie de servidors que corresponen a una tipologia d’un servei.

      Aquest codi serà de 2 dígits en tots els casos, tret de que el sistema operatiu no admeti més que 1 dígit. En qual cas, es farà servir un codi d’un dígit.

Exemple:

Per a un servidor Host de VMWare dedicat a instàncies de producció,el primer de la sèrie, es pot fer servir el nom:

Imatge 4

Part 6: Identificació nom DNS corresponent a IP de backup

  1. Per a definir adreces/noms de IP de backup s’ha de fer servir la codificació següent:

Imatge 41

Part 7: Identificació nom DNS corresponent a IP de servei o d’aplicació

Adreces/noms de servei de xarxa

  1. A més a més del nom de servidor (hostname), un servidor ha de tenir com a mínim una adreça IP de servei o d’aplicació, que es farà servir per a accedir als serveis oferts pel programari instal·lat a la mateixa. Es decidirà si és de servei o d’aplicació en funció de la granularitat que s’estigui oferint.

Resolució de noms de xarxa

  1. L’accés a aquestes adreces IP s’ha de fer mitjançant resolució del seu nom de DNS, i mai per IP directament, per nom ‘localhost’, o per nom en resolució local (p.e. fitxers /etc/hosts).

Connectivitat a les aplicacions

  1. Quan s’hagi d’accedir a una aplicació, es farà mitjançant aquestes adreces d’aplicació (que tindran noms publicats al DNS), i mai s’ha d’accedir-hi amb nom del servidor (hostname) Per accessos per DNS intern a aplicacions (o serveis), les aplicacions pertanyeran a una agrupació tècnica o funcional i aquesta s’haurà d’incloure al subdomini seguint el següent patró [nom_aplicacio/servei].[nom_agrupacio].intranet.gencat.cat.

    Per exemple, una aplicació d’un sistema iSeries (on el nom d’agrupació tècnica és AS400) que s’anomenés stt, s’enregistraria al DNS de la següent manera: stt.as400.intranet.gencat.cat

  2. Les aplicacions han d’estar configurades per a què esperin connexions (socket listen) únicament per les seves adreces IP d’aplicació, i de cap manera de forma genèrica o per la adreça IP corresponent al nom del servidor (hostname o localhost) o d’altres adreces administratives.

  3. Per a cada instància de component d’una aplicació existent a un servidor, s’ha de donar d’alta un nou nom de DNS que apuntarà a una de las adreces IP d’aplicació de la màquina (en funció del volum d’aplicacions a un servidor, pot ser convenient tenir més d’una adreça IP d’aplicació)

Part 8: Identificació d’instàncies de components d’aplicacions

  1. Les instàncies de components d’una aplicació (instàncies de servidor web, instàncies de bases de dades, instàncies de servidor d’aplicació, etc) han de rebre un nom específic. Aquest nom les identificarà de forma unívoca, i s’haurà de fer servir arreu a on s’hagi d’identificar una instància d’aplicació. La seva nomenclatura seguirà el mateix esquema que el dels noms DNS d’aplicació

    Imatge 5

  2. En el cas de desplegaments FileNet s’ha de reservar el primer caràcter de l’Index segons el component desplegat:

    Producte FileNet Caràcter identificatiu
    Content Engine (CE) C
    Application Engine (AE) A
    Content Search Engine (Legacy) I
    Workplace XT W
    Process Engine (PE) P
    Case Manager (ACM) E
    Content Federation Services (CFS) F
    Enterprise Records (RM) R
    Content Search Services (CSS) S
    Content Collector for SAP (CCS) L

  3. En el cas de desplegaments SAP s’ha d’usar la següent variant:

    • Dígits 1-3: Nom del servei.
    • Dígits 4-6: Nom d’instància SAP (el dígit 6 coincideix amb el codi d’entorn)
    • Dígit 7, tipus de servidor segons la següent taula:
    Servei desplegat Caràcter identificatiu
    Base de dades B
    Servei ASCS/SCS S
    Web Dispatcher W
    Enqueue Replication Server E
    Global Filesystem F
    Central Instance C
    Dialog Instance D
    • Dígit 8, índex de servidor:

    Exemple:

    Imatge 6

    Exemple:

    Suposem un servidor ‘wgauwix1’, en el qual tenim un servidor IIS i una base de dades Oracle, totes dues donant servei a l’aplicació codificada ‘stt’.

    Imatge 7

    En aquest cas, tindrem els següents noms de DNS:

    • wgauwix1: El hostname, o nom del servidor. Aquest es farà servir només per motius administratius (entrar al sistema com a un usuari administrador, etc) I, mai per a accés per part de les aplicacions.

    • sttwix01: Aquest nom estarà associat mitjançant DNS a una IP d’aplicació resident en aquesta màquina no coincident amb la del hostname. El faran servir tots els elements que hagin d’accedir al servidor IIS per la aplicació stt.

    • sttdox01: Aquest nom estarà associat mitjançant DNS a una IP d’aplicació resident en aquesta màquina no coincident amb la del hostname. El faran servir tots els elements que hagin d’accedir a la base de dades Oracle per l’aplicació stt.

    Aquesta política d’ús de noms DNS diferenciats del hostname facilita posteriors moviments d’infraestructura, alhora que permet un inventari més granular dels sistemes.

Part 9: Identificació de dominis interns de DNS

Aquest apartat aplica únicament a noms interns, i mai a noms d’aplicació publicats a Internet.

  1. Els dominis interns (intranet) de DNS seguiran la següent estructura:

    [codi_llarg_entorn|].nom_aplicacio.intranet.gencat.cat

    On codi_llarg_entorn s’omet en cas de ser producció.

    Exemple:

    Per a l’aplicació de Servei Tributari del servei G@udí, per exemple, tindríem els següents codis, per als entorns de producció, preproducció i integració:

    • Producció (codi elidit) : stt.intranet.gencat.cat
    • Preproducció: preproduccio.stt.intranet.gencat.cat
    • Integració: integracio.stt.intranet.gencat.cat

Part 10: Identificació de fitxers en entorns UNIX

Fitxer de descripció de filesystem

  1. A l’arrel de tot filesystem creat (s’exclouen d’aquesta norma els filesystems generats per la instal·lació del sistema operatiu) ha d’existir un fitxer anomenat .fsdesc. El propòsit d’aquest fitxer és mantenir una descripció de les característiques, funcionalitat i vida del filesystem.

  2. El fitxer de filesystem ha de contenir un Històric de modificacions (amb descripció de la modificació) del filesystem, amb una línia per cada modificació i ordenada de més nova a més antiga amb el següent format:

    data:tecnic:empresa:modificacio

    On: - Data. Ha de ser descrita en format invers. Exemple: 1 de juny de 2011 s’escriurà 20110601 - Tecnic. Nom del tècnic que fa la modificació - Empresa. Nom de la empresa proveïdora de serveis - Modificacio. resum de la modificació.

  3. Aquest històric ha d’incloure com a darrera entrada sempre la data de creació del filesystem.

  4. Les entrades han d’estar precedides per una línia amb l’etiqueta ‘HISTORIC’.

  5. El fitxer de filesystem ha de contenir una línea amb el camí de muntatge del filesystem, precedit per l’etiqueta ‘PATH’.

    Exemple:

    /serveis/dades/pro/actic/.fsdesc
    HISTORIC:
    20110630: Jordi Masdeu:T-Systems: Canvi permisos per usuari oracle.
    20110623: Josep Gràcia: T-Systems:Canvi path muntatge de /serveis/dades/pre/actic a /serveis/dades/pro/actic
    20110516: Josep Gràcia: T-Systems: Ampliació espai +200GB
    20110515: Jordi Masdeu: T-Systems: Creació tamany 500GB PATH: /serveis/dades/pro/actic
    PATH: /serveis/dades/pro/actic

Ubicació de scripts d’arrancada i aturada

  1. Tot sistema UNIX ha de tenir un directori on s’han d’ubicar els scripts que s’executin durant l’arrancada i aturada del servidor. Aquest directori s’anomenarà /serveis/scripts/pro/system/startstop

  2. En aquest directori ha d’existir sempre un script mestre d’arrencada de totes les aplicacions no relacionades amb el sistema operatiu, que es dirà start.sh.

  3. En aquest directori ha d’existir sempre un script d’aturada de totes les aplicacions no relacionades amb el sistema operatiu que es dirà stop.sh

Ubicació scripts de còpies

  1. Tot sistema UNIX ha de tenir un directori a on s’han d’ubicar els scripts de còpies. Aquest directori s’anomenarà /serveis/scripts/pro/system/backup

Ubicació scripts monitoratge/sondatge

  1. Tot sistema UNIX ha de tenir un directori on s’han d’ubicar els scritps de monitoratge i sondatge. Aquest directori s’anomenarà /serveis/scripts/pro/system/sondes

Ubicació logs

  1. Els logs (tant d’eines com d’aplicacions) als sistemes UNIX han de residir sempre sota un sistema de fitxers anomenat:

    • Unix: /var/log/
    • Windows: <Unitat>:\var\log\

  2. Per sota d’aquest, si es considera clarificador, es permet un segon nivell en funció de l’aplicació. En aquest cas, el nom del sistema de fitxers serà:

    • Unix: /var/log/codi_llarg_entorn/nom_servei|nom_aplicació
    • Windows: <Unitat>:\var\log\codi_llarg_entorn\nom_servei|nom_aplicació

    Com a exemple, i continuant amb el cas anterior per l’aplicació Servei Tributari, el directori per a logs de producció es diria: /var/log/pro/stt

  3. No han d’existir logs dins de cap altre camí que no sigui aquest. En cas que una aplicació no permeti configurar la ubicació del directori de logs, s’haurà de fer un symlink des de la ubicació del directori de logs de l’aplicació cap al sistema de fitxers adient (/var/log/codi_llarg_entorn/nom_aplicació)

Ubicació binaris/instal·lacions de producte.

  1. El camí dels directoris d’instal·lació de producte ha de seguir el següent patró:

    /opt/nom_fabricant/producte

    Per exemple, en el cas de Control-M, del fabricant BMC, el camí d’instal·lació del producte ha de ser: /opt/BMC/controlm

  2. En cas de desconeixement del codi a aplicar, cal adreçar-se a la Unitat d’Integració de solucions del CTTI (mailto:uit.ctti@gencat.cat), que establirà quin és el codi més adient, o bé crearà un de nou que serà llistat en la propera versió d’aquest document.

Ubicació de dades/configuració/scripts

  1. El camí dels directoris de dades aplicatives, configuració i scripts ha de seguir el següent patró:

    Imatge 8

  2. No han d’existir dades, fitxers de configuració o scripts dins de cap altre camí que no sigui aquest. En cas que una aplicació no permeti configurar la ubicació d’aquests elements, s’hauràn de fer symlinks des de la ubicació requerida per la aplicació cap als directoris consignats en aquest document. En base a això, el directori de dades de l’aplicació ‘Home Generalitat’ (codi d’aplicació hmg) per a l’entorn de producció, al servei Hosting Internet (codi de servei: hoi) hauria de ser el següent:

    /serveis/dades/pro/hoi/hmg/

    A modus d’exemple, podem veure aquest gràfic d’arbre de directoris:

    Imatge 9

Còpies de seguretat de fitxers (amb dates):

  1. Sempre que s’hagi de fer una còpia d’un fitxer (configuració, dades, etc), amb una data associada, la data s’haurà de posar en format invers, unida al nom del fitxer pel signe punt (‘.’)

    Exemple:

    cp /etc/hosts /etc/hosts.20110630

  2. En cas que es faci més d’una còpia el mateix dia, s’ha de fer servir un índex per les properes, separant amb el signe guió (‘-‘). Això facilitarà la visualització i identificació de forma ordenada quan s’hagi de fer un llistat del directori.

    Exemples:

    cp /etc/hosts /etc/hosts.20110630 
cp /etc/hosts /etc/hosts.20110630-1 
cp /etc/hosts /etc/hosts.20110630-2

Usuaris de sistema

  1. Es defineixen com a usuaris de sistema aquells que es fan servir per a l’execució d’aplicacions o com a propietaris de directoris i fitxers, però no representen a cap persona (exemple: oracle, httpserv, etc)

  2. No s’ha de poder accedir al sistema amb un usuari de sistema (login inhabilitat)

  3. Els usuaris de sistema no han de tenir un password definit.

  4. Tots els accesos a un compte d’usuari de sistema s’han de fer mitjançant eina tipus ‘sudo’.

  5. La nomenclatura dels usuaris de sistema ha de seguir el següent patró:

    Imatge 10

    D’aquesta manera, el nom que s’hauria de fer servir per a executar la primera instància de l’aplicació GSIT a l’entorn de producció és:

    Imatge 11

ANNEX A (normatiu) Nomenclatura dels codis identificadors

Entorns

  1. S’ha d’identificar en el nom d’un servidor de quin entorn usant la següent nomenclatura:
Entorn Format curt Format llarg
Producció x Pro
Pre-producció t (test) Pre
Integració i Int
Desenvolupament d Des
Proves de sistemes s Prs
Proves de proveïdor e Prp
Formació f Frm
Consolidació c Con

Aplicació

  1. S’ha d’assignar un codi únic de tres dígits exactes a l’aplicació. Aquest codi haurà de ser unívoc per a cada aplicació que existeixi a la instal·lació, i serà proposat pel proveïdor de CPD i validat pel CTTI, per la Unitat de Gestió de Serveis de CPD, que mantindrà la llista de tots els codis.

Servei

  1. S’ha d’assignar un codi únic de tres dígits exactes al servei del catàleg de serveis CTTI. Aquest codi ha de ser únic per a cada servei que existeixi a la instal·lació, i serà designat des del CTTI per la Unitat de Gestió de Catàleg de Serveis (catalegserveis.ctti@gencat.cat), que mantindrà la llista de codis. Aquesta llista es podrà consultar a l’aplicació d’inventari de ‘Projectes i Serveis’ (PIS), mantinguda per la ‘Oficina de Gestió de la Demanda’ (OGD)

    A mode d’exemple, podem considerar un cas hipotètic, per al servei ‘G@udí, al qual s’ha assignat el codi de servei ‘gau’. Aquest exemple es farà servir més endavant al llarg del document.

  2. Per a infraestructures transversals, que donen o donaran servei als departaments, el codi de servei s’ha de construir utilitzant una associació de lletres (segons plataforma) i números (segons departament). Es defineixen els següents codis de plataforma i departament:

    Plataforma Codi
    Web-IIS I
    Web-Apache A
    App-Weblogic W
    App-Jboss J
    App-Tomcat T
    App-.Net N
    App-NodeJs P
    BBDD-Oracle O
    BBDD-SQL Server S
    BBDD-MySQL M
    BBDD-MongoDB G
    Departament Codi
    CTTI 01
    ENS 02
    ECO 03
    EADOP 04
    GOV 05
    INCASOL 06
    PRES 07
    BSF 08
    ICS 09
    EMO 10
    TES 11
    GOV 12
    DAAM 13
    SOC 14
    ACT 15
    CLT 16
    JUS 17
    CORP 18
    SLT 19

A mode d’exemple, pels Apaches de la SUR (Secretaria d’Universitats i Recerca) s’assignaria el ‘A20’.

Tipus de programari

  1. S’ha d’assignar un codi únic d’un dígit exacte al tipus de programari. Aquest codi haurà de ser únic, i definirà agrupacions lògiques de programari. Es defineixen els següents codis:

    Tipus de programari Codi Descripció
    Web Server w Servidors de planes web o ‘front ends’, com ara Apache, IIS, etc.
    Base de dades d Servidors de bases de dades, com ara Oracle, SQL Server, MySQL, MongoDB, etc.
    LDAP l Servidors de directori LDAP, com ara MS Active Directory, OpenLDAP, etc.
    Content Manager c Servidors de continguts, com ara Documentum, FileNet, Alfresco, Vignette, etc.
    Servidor d’aplicacions s Servidors d’aplicacions, com ara WebLogic, Tomcat, JBOSS, SAP, Service Desk, NodeJs etc.
    File transfer x Servidors de transferència de fitxers, com ara ftp’s, sftp’s, etc.
    Monitoratge m Aplicacions de monitoratge
    ERP e Servidors de ERP, com ara SAP, Navision, etc.
    Servei d’aplicació a Servei propi del programari del Servei.
    Host (Infr. Virtualització) h Sistemes host (no necessàriament tipus Mainframe)
    Virtual IO Server o Sistema dedicat a serveis de IO en una infr. de virtualització
    NAS n Dedicat a serveis tipus NAS
    Servidor Videoconferència v
    Servidor de provisió de plataforma p Codi per a Servidors de provisió de plataforma.

Model de programari

  1. S’ha d’assignar un codi únic d’un dígit exacte al model de programari, que s’ha de conjugar amb el codi de tipus de programari per fer un codi únic de dos dígits. Es defineixen els següents:

    Model de programari Codi
    Web Server Apache a
    Web Server IIS I
    Base de dades Oracle O
    Base de dades MS SQLServer S
    Base de dades DB2 D
    Base de dades MySQL M
    Base de dades MongoDB G
    LDAP OpenLDAP O
    LDAP Active Directory A
    Content Manager Documentum D
    Content Manager Filenet F
    Content Manager Vignette V
    Content Manager Sharepoint S
    Content Manager Alfresco A
    Servidor d’aplicacions SAP S
    Servidor d’aplicacions Weblogic W
    Servidor d’aplicacions Tomcat T
    Servidor d’aplicacions JBOSS J
    Servidor d’aplicacions Service Desk D
    Servidor d’aplicacions Navision N
    Servidor d’aplicacions MicroStrategy M
    Servidor d’aplicacions NodeJs P
    File transfer ftp F
    File transfer scp S
    Monitoratge OVI O
    NAS A
    Host ESX e
    Host AIX a
    Host HP-UX h
    Host Solaris s
    Servidor Videoconferència c
    Altres u
    Ignite Server (p a tipus de programari) i
    Nim Server (p a tipus de programari) n
    Jumpstart (p tipus de programari) j

En cas de desconeixement de quin codi aplicar, cal adreçar-se a la Unitat d’Integració de Solucions (uit.ctti@gencat.cat), que establirà quin és el codi més adient, o bé crearà un de nou que s’afegirà en una propera versió d’aquest document.

Sistema operatiu

  1. S’ha d’assignar un codi únic d’un dígit exacte al tipus de programari. Aquest codi haurà de ser únic, i definirà agrupacions lògiques de programari. Es defineixen els següents codis:

    Sistema operatiu Codi
    Solaris s
    AIX a
    HP-UX h
    Linux l
    Windows w
    VMWare v
    Específic e