Ets el DBA d'una empresa fictícia. L'empresa té una aplicació de gestió (ERP) i un equip de persones
que treballen directament amb la base de dades, i t'encarrega desplegar-ne un únic servidor
que els atenga a tots, i controlar qui hi accedeix i què hi pot fer.
Ho faràs amb Docker, amb Oracle o PostgreSQL (a la teua elecció).
Més avall tens 8 requisits que el servidor ha de complir i una ampliació opcional.
Els requisits 1 a 6 tracten la instal·lació i la configuració del servidor, i els requisits 7 i 8,
el control d'accés.
Cadascun indica la necessitat de l'empresa, què s'ha de complir i què has de demostrar.
No t'indiquem quins fitxers ni quins paràmetres has de modificar: això ho has de descobrir i justificar tu.
El diagrama resumeix l'estructura: qui es connecta al servidor, des de quina xarxa,
i el servidor de base de dades que has de desplegar.
flowchart LR
subgraph int["Xarxa interna · 172.30.0.0/24"]
subgraph apps["Aplicació"]
erp1["ERP<br/>instància 1"]
erp2["ERP<br/>instància 2"]
erp3["ERP<br/>instància 3"]
end
subgraph pers["Persones"]
personal["Personal<br/>de RRHH"]
analistes["Analistes"]
end
end
subgraph vis["Xarxa de visitants · 172.31.0.0/24"]
visitant["Client visitant"]
end
subgraph srv["Servidor de base de dades (Docker) · 2 GB de RAM"]
db["SGBD<br/>Oracle o PostgreSQL"]
discerp[("Espai de l'ERP")]
discrrhh[("Espai dels<br/>empleats")]
end
erp1 & erp2 & erp3 -->|"15 connexions<br/>cadascuna"| db
personal & analistes --> db
visitant -.->|"no ha de poder<br/>connectar"| db
db --> discerp
db --> discrrhh
linkStyle 5 stroke:#d33,stroke-width:2px,color:#d33
Les taules següents detallen les dades de l'escenari.
Aplicació de gestió de l'empresa (comandes, factures, estoc…). S'executa 3 vegades a la vegada. Cada instància obri fins a 15 connexions simultànies a la base de dades. Les seues dades creixen molt.
A més de l'ERP, algunes persones es connecten directament a la base de dades
des dels seus equips, a la xarxa interna. Treballen amb les dades dels empleats (RRHH),
que no pertanyen a l'ERP: són menudes i estables.
Grup
Persones
Què fan
Personal de RRHH
2
Gestionen les dades dels empleats, incloent-hi els salaris.
Analistes
3
Fan informes amb les dades de l'ERP i dels empleats, però no poden veure els salaris. La plantilla d'analistes canvia sovint.
Demostra que: pots destruir el servidor, tornar-lo a crear, i les dades hi continuen.
Accés restringit a la xarxa interna
Necessitat: només l'ERP i el personal de la xarxa interna poden connectar-se
al servidor. Ningú més, ni tan sols des d'una altra xarxa que arribe al servidor.
Cal que:
El servidor estiga connectat a les dues xarxes (aplicació i visitants).
El sistema gestor de bases de dades rebutge les connexions que vénen de la xarxa de visitants.
No val que no hi haja ruta: el rebuig ha de ser decisió del SGBD.
No es publique cap port al host.
Demostra que: un client a la xarxa interna connecta i un client a la xarxa de visitants
és rebutjat. Obri un contenidor client a cada xarxa per a provar-ho.
Memòria
Necessitat: el servidor disposa de 2 GB de RAM i ha d'aprofitar-los bé, sense quedar-se curt
ni passar-se. Si el servidor intenta usar més memòria de la que té el contenidor, Docker el mata.
Context: un SGBD no usa la memòria d'una sola manera. Una part és compartida per tot el servidor
(per exemple, la caché de dades que evita llegir del disc). Una altra es reserva per sessió o per
operació (per exemple, per a ordenar resultats o fer combinacions de taules), i per tant creix
amb el nombre de connexions. A més, el sistema operatiu i els processos interns del propi servidor
també necessiten memòria.
Cal que:
Identifiques els paràmetres del teu SGBD que controlen aquestes dues classes de memòria
(la compartida i la per sessió o operació).
Els configures amb valors calculats, de manera que la suma, en el pitjor cas, càpiga
en els 2 GB i deixe marge per al sistema operatiu.
Justifiques el repartiment amb un càlcul escrit (què reserves per a cada cosa i per què).
El nombre de connexions del requisit 4 t'influeix.
Demostra que:
Hi ha un paràmetre de memòria que es pot canviar sense reiniciar el servidor:
mostra el valor abans i després, consultant el servidor.
Hi ha un altre que requereix reiniciar-lo: canvia'l i mostra que el valor en ús no canvia
fins que reinicies.
Què entregaràs: una taula amb cada paràmetre triat, el seu valor, el càlcul que el justifica i
l'eixida del servidor que demostra el valor en ús.
Connexions
Necessitat: el servidor ha d'admetre totes les connexions que l'ERP i el personal poden obrir a la vegada,
però no més de les necessàries.
Cal que:
Calcules el nombre màxim de connexions simultànies a partir de l'escenari.
Justifiques el valor (no cal que siga exacte, sí que es puga defensar).
Demostra que: quan se supera el límit, el servidor rebutja la connexió i mostra l'error corresponent.
Emmagatzematge
Cal que:
Hi haja almenys 2 espais d'emmagatzematge (tablespaces), un per a les dades de l'ERP
i un altre per a les dels empleats, en volums diferents.
Les dades dels espais d'emmagatzematge es mantinguen quan es reinicia el contenidor.
Demostra que:
Saps on és físicament cada espai, consultant el diccionari de dades.
Després de reiniciar el contenidor, les dades dels dos espais hi continuen.
Traçabilitat
Necessitat: si algú intenta connectar-se sense permís, ha de quedar constància, encara que
el contenidor es destruïsca.
Cal que:
Els registres del servidor s'escriguen en un fitxer, en una ubicació persistent.
Demostra que: els intents de connexió rebutjats del requisit 2 apareixen en eixe fitxer.
Compte de l'aplicació
Necessitat: l'ERP ha d'accedir només a les seues dades, i un error o un atac en l'aplicació
no ha de poder modificar l'estructura de la base de dades. A més, l'aplicació no es pot quedar
sense accés de manera inesperada.
Cal que:
Les dades de l'ERP i les dels empleats pertanguen, cadascuna, a un compte propietari propi,
que ningú utilitze per connectar-se, i es guarden en el seu espai d'emmagatzematge (requisit 5).
L'ERP es connecte amb un compte diferent del propietari, que només puga
consultar i modificar les dades de l'ERP.
El compte de l'ERP no puga obrir més connexions de les que necessiten les seues instàncies
(requisit 4).
La contrasenya del compte de l'ERP no caduque.
Demostra que:
El compte de connexió de l'ERP pot inserir dades, però no pot crear ni eliminar taules.
Quan el compte de l'ERP supera el seu límit de connexions, el servidor el rebutja.
Accés del personal
Necessitat: el personal de RRHH i els analistes es connecten directament a la base de dades.
Cada persona ha de tindre el seu compte, i la plantilla d'analistes canvia sovint: donar d'alta
o de baixa una persona no pot suposar revisar els privilegis un a un.
Cal que:
Cada persona tinga un compte propi, amb una contrasenya que caduque com a màxim cada 90 dies.
Els privilegis s'assignen a grups de privilegis (rols), un per perfil de treball,
i no directament a les persones.
El personal de RRHH puga consultar i modificar les dades dels empleats.
Els analistes puguen consultar les dades de l'ERP i dels empleats, però no els salaris.
Afig una columna de salari a les dades dels empleats si no en tenen.
Demostra que:
Un analista pot consultar les dades dels empleats, però la consulta del salari és rebutjada.
Quan s'incorpora un analista nou, n'hi ha prou amb assignar-li el rol dels analistes
perquè puga fer les mateixes consultes que la resta, sense concedir-li cap privilegi més.
Quan un analista se'n va, n'hi ha prou amb retirar-li el rol perquè perda tots els privilegis.
Ampliació: Caiguda sobtada
Necessitat: el servidor pot caure en qualsevol moment (una fallada elèctrica, per exemple)
i no pot deixar les dades en un estat inconsistent.
Cal que:
El servidor estiga configurat per a tornar-se a alçar sol si el procés cau.
Demostra que:
Després de simular una caiguda sobtada, una transacció confirmada (amb COMMIT)
es conserva i una sense confirmar es descarta.
Existeix una configuració que millora el rendiment de les confirmacions a canvi de durabilitat:
investiga-la i intenta reproduir un cas en què es perga una transacció confirmada.
Lliura un únic document (p1/README.md) que explique tot el treball relacionat amb la pràctica:
les ordres executades, l'eixida obtinguda i per què has pres cada decisió (no només el "com").
No hi ha una única solució correcta: es valorarà el raonament i la justificació basada en evidències.
Les demostracions han d'estar recolzades per consultes al diccionari de dades o per
l'eixida del servidor, no per captures d'un fitxer editat.
La pràctica es validarà oralment: se't demanarà canviar un paràmetre o donar d'alta
una persona en directe, i explicar per què has triat cada configuració.
El lliurament ha d'incloure un script p1/setup-env.sh que munte tot l'escenari de la pràctica
a partir d'un clon net del repositori: crear i arrancar els contenidors, aplicar la configuració
i executar els fitxers SQL necessaris (tablespaces, usuaris, rols, privilegis...).
p1/setup-env.sh
#!/usr/bin/env bashset-euopipefail
cd"$(dirname"$0")"### CONTENIDORS# Crea/arranca els contenidors si cal i espera que estiguen sans (healthy)dockercomposeup-d--wait
### FITXERS DE CONFIGURACIOdockercpconfig/...confempresa-db:/var/lib/postgresql/data/...conf
### EXEMPLE LLANÇAMENT CONSULTES SQLdockerexec-iempresa-dbpsql-Upostgres<sql/consultes.sql
p1/docker-compose.yml
services:db:container_name:empresa-dbimage:postgres:16.4environment:# ...volumes:# ...healthcheck:# Comprovació per TCP: durant la inicialització el servidor temporal només escolta pel socket Unixtest:["CMD-SHELL","pg_isready-h127.0.0.1-Upostgres"]interval:2stimeout:5sretries:30start_period:10s
