|
|
Italia - Italiano | |
|
|
 |
|
Gestione di sistemi e gruppi di lavoro: Guida per gli amministratori di sistema HP-UX > Capitolo 2 Pianificazione di
un gruppo di lavoro
Distribuzione delle applicazioni e dei dati |
|
|
Gli argomenti che seguono hanno lo scopo di aiutare a pianificare la configurazione complessiva del gruppo di lavoro, in termini di quali parti del flusso di lavoro risiedono ed eseguono su quali sistemi. Questa sezione avrà più senso se si è già letto “Scelta di un modello di condivisione dei file”; si noterà che la discussione tende verso il “Modello client-server”. Per ulteriori informazioni, consultare uno dei seguenti argomenti: HP-UX ha introdotto un nuovo layout di file system con 10.0. Il nuovo layout si basa sui file system AT&T SVR4 ed OSF/1 ed ha lo scopo di fornire vantaggi quali:
Per ulteriori informazioni, consultare la HP-UX 10.0 File System Layout White Paper alla pagina http://docs.hp.com. Il nuovo layout è più lineare e più logico del 9.x, è essenziale per NFS Diskless (consultare “Modello NFS Diskless”) e dovrebbe rendere più semplice l’interoperatività con altri rivenditori di sistemi UNIX. Non modifica la meccanica della configurazione dei montaggi NFS, ma facilita la loro gestione sotto un aspetto importante: la segregazione di applicazioni non di “sistema” sotto /opt e le modifiche che applicazioni come Netscape hanno fatto rispettare, significano che il server ora può esportare una data applicazione da un’unica sottodirectory sotto /opt, invece che dover esportare varie sottodirectory per ogni applicazione, o perfino l’intera /usr/local. Il paradigma di condivisione dei file V.4 divide le directory di HP-UX in due categorie: private e condivise (a volte denominate anche dinamiche e statiche). Le directory contenenti le informazioni sulla configurazione di un sistema si designano come private e non devono essere condivise attraverso NFS. Esse sono:
Il modello definisce anche /home (per le home directory degli utenti), /tmp e /mnt (per i montaggi locali) come private, sebbene in pratica esista un argomento per la condivisione di /home e /var/mail (consultare “Occorre condividere la home directory e la directory della posta degli utenti?”). Inoltre, /opt stesso non deve essere condiviso, sebbene le sue sottodirectory siano le prime candidate per la condivisione. Le directory definite come condivisibili sono:
In pratica, tranne che sotto NFS diskless (consultare “Modello NFS Diskless”) non è una buona idea condividere /sbin o directory sotto /usr diverse da /usr/local perchè crea troppa dipendenza (il client NFS non può funzionare a meno che il server NFS sia attivo) e perchè ciò provocherà dei problemi quando si tenterà di aggiornare i sistemi ad una nuova release di HP-UX. HP consiglia di implementare queste configurazioni così strettamente accoppiate soltanto sotto NFS Diskless (attualmente limitato ai sistemi 10.x). Le directory da prendere in considerazione per la condivisione sono:
Ad esempio, gli autori del presente documento conservano il testo sorgente su un file server, un sistema Serie 800 che esegue HP-UX 10.20, del quale si esegue il backup nottetempo. I nostri strumenti per gli autori e web browser risiedono su un server delle applicazioni, un server Classe K che esegue 10.20, su cui si realizza la manutenzione di tutto il software. Non si esegue il backup dei nostri dischi locali, i quali non contengono applicazioni e strumenti che richiedano supporto esterno. I criteri principali sono qui le prestazioni e la facilità di gestione. Le possibilità pratiche sono:
L’unica configurazione che probabilmente occorre non prendere in considerazione fin dall’inizio è di installare ciascuna applicazione singolarmente sui dischi locali di ogni workstation; ciò potrebbe avere senso per il singolo utente occasionale con necessità particolari, ma le considerazioni di gestione del software lo rendono pressoché impensabile come approccio generale. Dato per assodato che si memorizzeranno le applicazioni su uno o più server, è meglio eseguirle sulle workstation (attraverso NFS) o sul server? Vi sono delle opinioni discordi ed in pratica si potrebbero benissimo combinare i due approcci. Ma occorre tener presente che le applicazioni moderne sono ad intensità di scambio e di memoria e spesso è meglio concentrare queste risorse su un server piuttosto che parcellizzarle su singole workstation. Per la massima facilità di gestione (backup e manutenzione del software) occorre:
Mirare alla configurazione più semplice in linea con prestazioni accettabili. La parte utile di qualsiasi sistema di computer è composta da applicazioni e dai dati che esse manipolano. Il proprio compito è di decidere le modalità di sfruttamento delle applicazioni e dei dati del gruppo di lavoro in modo che possano essere tranquillamente accessibili, disponibili e sicuri. Questa sezione sottintende che:
Occorre pianificare di tenere le applicazioni condivise in una ubicazione centrale dove le si installa, configura, si esegue il backup e la manutenzione. Allo stesso modo, occorre pianificare di conservare tutti i dati condivisi dagli utenti, e quanti più dati volatili possibili (cioè, dati che cambiano di frequente, a prescindere o meno dalla loro condivisione da parte di più di un utente) in una ubicazione centrale dove sia possibile eseguire il backup facilmente, e da cui siano distribuiti alle workstation attraverso NFS. Un sistema i cui dischi contengano dati condivisi di solito si chiama file server (anche se i dati effettivamente risiedono in database piuttosto che in file ordinari). Un sistema sul quale le applicazioni condivise vengono conservate potrebbe chiamarsi server delle applicazioni o compute server; noi utilizzeremo server delle applicazioni. In molti gruppi di lavoro, il file server ed il server delle applicazioni sono la stessa macchina, che è semplicemente un magazzino per tutto ciò che è condiviso e tutto ciò che richieda un backup regolare. Ciò potrebbe essere comodo e può rappresentare la miglior cosa da fare con l’hardware disponibile, ma non è l’ideale perché le funzioni di un file server sono diverse da quelle di un server delle applicazioni e possono interferire con loro. Ad esempio, una CPU che è occupata a gestire le richieste NFS avrà meno cicli per eseguire le applicazioni. Di solito, gli utenti non si collegano ad un file server; ottengono i dati che a loro servono da esso mediante montaggio NFS. I requisiti principali per un file server sono:
Questa lista non intende certo dire che la potenza della CPU non sia importante in un file server, ma soltanto che non è così importante come in un server delle applicazioni. Se si dispone, o ci si può permettere di acquistare, le risorse hardware, occorre installare le applicazioni su un sistema al quale gli utenti possono collegarsi ed eseguirle. Che lo facciano o meno dipenderà in parte dalla quantità di potenza e capacità di cui dispongono sui propri desktop, in parte dalle prestazioni della LAN, in parte dalla compatibilità dell’OS/applicazione, ma è probabile che almeno alcuni utenti del gruppo non saranno in grado di eseguire tutte le applicazioni di cui necessitano a livello locale e che altri preferiranno non farlo perché, per una ragione o per l’altra, le prestazioni a livello locale sono scadenti. E naturalmente alcune applicazioni, tipo le applicazioni database di grandi dimensioni, per loro natura necessitano di capacità che non è probabile si trovino su un desktop qualsiasi. Un server delle applicazioni, allora richiede:
Per ragioni di compatibilità delle applicazioni, un server delle applicazioni potrebbe anche necessitare di più frequenti aggiornamenti del sistema operativo rispetto ad un file server. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Versione stampabile |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
