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 |
![]() Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-CompartirIgual 4.0 Internacional de Creative Commons |
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.
No aplica
No aplica
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:
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:
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:
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:
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
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.
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ó)
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ó
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 |
En el cas de desplegaments SAP s’ha d’usar la següent variant:
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 |
Exemple:
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’.
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.
Aquest apartat aplica únicament a noms interns, i mai a noms d’aplicació publicats a Internet.
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ó:
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.
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ó.
Aquest històric ha d’incloure com a darrera entrada sempre la data de creació del filesystem.
Les entrades han d’estar precedides per una línia amb l’etiqueta ‘HISTORIC’.
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 |
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
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.
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
/serveis/scripts/pro/system/backup
/serveis/scripts/pro/system/sondes
Els logs (tant d’eines com d’aplicacions) als sistemes UNIX han de residir sempre sota un sistema de fitxers anomenat:
/var/log/
<Unitat>:\var\log\
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à:
/var/log/codi_llarg_entorn/nom_servei|nom_aplicació
<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
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ó)
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
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.
El camí dels directoris de dades aplicatives, configuració i scripts ha de seguir el següent patró:
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:
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
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
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)
No s’ha de poder accedir al sistema amb un usuari de sistema (login inhabilitat)
Els usuaris de sistema no han de tenir un password definit.
Tots els accesos a un compte d’usuari de sistema s’han de fer mitjançant eina tipus ‘sudo’.
La nomenclatura dels usuaris de sistema ha de seguir el següent patró:
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:
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 |
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.
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’.
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. |
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.
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 |