Vademecum dell’Amministratore Domino

BEGINNER Q-A TIPS ADMIN

  • 9 commenti
Non so voi.... ma più vedo installazioni domino e più mi rendo conto che solo domino può fare miracoli..... negli ultimi anni ho visto installazioni di tutti i generi (immagino anche voi) ma certe cose proprio non le sopporto.... e mi sono deciso a scrivere (a costo di essere scontato, rompiscatole, ripetitivo, precisino.... etc...) un vademecum su cosa non si deve mai fare con domino e cosa è altamente consigliato:


Cosa non devi mai fare su un Domino Server:

1.        MAI dico MAI abilitare la compressione delle cartelle di Windows e pensare di comprimere la Directory DATA di Domino.... si certo domino continua a funzionare (e quì il miracolo di un Server Solido) ma non crediate che vada bene.... le performance cadono a picco (l'I/O sui dischi diventa più simile a quello un masterizzatore 12x) e detto tra noi la compressione dei database non è supportata in nessuna forma (tranne le funzionalità native lato .NSF).
2.        Mai accedere a database di domino .NSF via share, o qualsiasi altro metodo di Browsing dei file che non passi dai protocolli di domino....
3.        Mai copiare un Database a caldo con strumenti diversi dalla copia o replica di database tramite client notes o comandi da console domino. Si otterrebbero solo database corrotti nella destinazione.
4.        Mai e poi Mai lasciare che l'Antivirus di OS controlli in scansione "Real Time" le directory di domino. Escludere sempre la Dir DATA; la directory temp di windows se non avete cambiato la posizione che ovviamente vi conisglio (parametro notes.ini: View_Rebuild_Dir=D:\nomecartella). Nel migliore dei casi il server domino si siederà quando l'antivirus vedrà un accesso ai database (praticamente sempre e costantemente).... nel peggiore dei casi (già visto) vi chiederete come mai è sparito un database e ve lo ritrovate (se siete fortunati) nella quarantena dell'antivirus.
5.        Tralascio le solite cose che dovreste sapere... Evitare di fare 1500 viste in un db per vedere quattro dati in croce ordinati per ogni possibile colonna immaginabile.... usate il cervello e imparate a programmare come Dio comanda... altrimenti fate come me.... non fate i programmatori e sparate a "0" su di loro..... :) così è più facile. PS anche le ACL sulle viste sono caldamente sconsigliate per motivi di performance.
6.        Se abilitate la Shared mail (non confondetela con DAOS) non venite a piangere sui forum.... "Velo meritate" ;)... "uomo avvisato mezzo salvato"
7.        Se installate un server di replica in DMZ per la pubblicazione della posta (io lo considero un metodo che risale al concetto dei tempi della R5 ma accettabile soprattutto per motivi di passthrough) non impostate come mail server il server in dmz. Questo perchè?.. se anche la cosa è "gradevole" perchè assicuro la posta in real time per gli utenti webmail (dato che mi insegnate che la replica non può essere schedulata sotto i 5 minuti)..... quando un giorno imparerete ad usare le policy e proverete ad applicarle... direte... mhhhh che "merda questo domino" le policy non funzionano.... e Lotus domino risponderà..... e grazie al "C.....O" come fa il cliente ha scaricare le policy???.... le policy vengono scaricate quando il client accede (open Db o replica) al suo e solo suo mail server. Quando pensate che il vostro client in LAN accederà al server in DMZ????.... lascio a voi la risposta. PS: ovviamente se usato con cognizione di causa lo posso anche accettare ma questo significa che lo avete fatto e che sapete cosa state facendo. Il fatto che domino sia piuttosto "duttile" ha aspetti positivi (si riescono a fare molte cose che vanno a finire nella sezione Undocumented) e aspetti negativi (si riesce a manomettere il funzionamento Standard della piattaforma)..... un esempio per tutti.... potete editare il campo "Full name" del utente e cambiare quello strano /ORGANIZZAZIONE in quello che volete... ma poi non funziona più un "Cavolino di Bruxell" per quel povero utente.... che "pensa la Sfiga" era l'amministratore delegato......
8.        Mai tenere sullo stesso server 2 o più database con la stessa ID di replica.... quando un altro server o client istanzierà una replica userà la ID per determinare il target ..... NON USA IL NOME FILE.... ergo immaginatevi che casino può succedere... con quale database replicherà??? .Nel migliore dei casi replicherà con entrambe. L'apoteosi del disastro la otteniamo se tale copia di database con la stessa replica id viene tenuta per database come la "Domino Directory" (alias names alias NAB alias "il cuore di domino"). Qunate volte si vede "copia_names.nsf, o "backup_names.nsf" nella dir DATA???... fare le copie va benissimo ma fuori dalla Directory DATA.
9.        LA Replica della NAMES.NSF e dell'ADMIN4.nsf non è una opzione a vostra scelta è un obbligo!!!!!!!!!! non avere la names e admin4 replicati costantemente tra i server genera una tale quantità di anomalie (tutte ricostruibili e riconducibili) che voi neanche immaginate.... e se le immaginate allora replicate.



Best Practise su domino:

1.        Performance: 2 dischi in raid 1 (o più dischi in RAID 10) per la Dir DATA costano si ma le performance del I/O sono notevolmente alte (ovviamente qualsiasi manuale di database Enterprise vi dirà le stesso cose... magari in 500 pagine). Se non è possibile allora possiamo optare per un RAID 5 per la Directory data + 2 dischi in RAID 1 per il transactional logging (se usato) + 2 dischi in RAID 1 per a directory di indicizzazione dei database (inteso area temporale per la costruzione degli indici ON fly prima della scrittura nel database)
2.        Non mettete Transactional log e database .NSF sullo stesso disco/partizione. Usate "Meccaniche" differenti. Se proprio non potete farne a meno meglio che il TL stia sul disco C (del OS) che non sulla partizione dei Database (presumendo che C sia su meccanica differente o CMQ controller differente.
3.        Se disponibile più di una CPU fisica aumentate gli update paralleli (notes.ini: updaters=2). Aumentate di 1 per ogni CPU fisica
4.        Su piattaforma a 32 bit + di 4GB di ram non servono a nulla (inteso come dare più di 4GB alla applicazione Lotus Domino) .... domino al max può allocare 3GB indirizzati alla sua memoria. Domino a 32 bit su ambiente a 64 bit (se supporta il Large memory) arriva al max a prendere 4GB per Partizione. Quindi attenzione una installazione PARTIZIONATA di domino a 32 bit dove posso installare fino a 6 Partizioni logiche il calcolo della memoria per partizione è max 3-4gb. Ipotizando una installazzione con 3 partizioni domino potremo dare ad ognuna fino a 4Gb per un totale di 12Gb (PS sono riferimenti di massima che possono cambiare da sistema operativi diversi; linux, windows, iSeries, etc..).
5.        Portate l'ODS dei database alla versione più aggiornata (ma ovvamente supportata) possibile dei server....ne avevo già parlato nella presentazione delle novità della 8.5 ma ci tengo a sottolinearlo.... upgradare un server domino è Banale... ma ci sono delle attività che richiedono tempo... per esempio eseguire il compact -C dei db per portare in alto l'ODS:

Release 6.x e 7.x = ODS massimo consentito = 43 (non richiede parametri nel notes.ini.... basta un compact del database)
Release 8.x = = ODS massimo consentito = 48 (richiede esplicitamente nel notes.ini del server il parametro: CREATE_R8_DATABASES=1 altrimenti viene mantenuto l'ODS 43
Release 8.5 = = ODS massimo consentito = 51 (richiede esplicitamente nel notes.ini del server il parametro: CREATE_R85_DATABASES=1 altrimenti viene mantenuto l'ODS 43 o 48 se presente il paramtro della R8.x
6.        L'ODS non cambia in nessun modo il funzionamento di un database.... anche il database più vecchio della Terra continuerà a funzionare.... e udite udite andrà anche meglio
7.        Se spostate un .NSF via file system sotto la dir DATA di domino in funzione.... eseguite sempre un fixup del db per "inizianizzarlo".

Se avete altre (immagino di si) esperienze frustranti.... o dopo questo post avete paura a mettere mano a domino... allora commentate....
Ovviamente commentate anche se ritente ce abbia detto "cavolate".... d'altra parte c'è sempre qualcuno che ne sa di più ;)

9 Commenti:

  • #1 Andrea 04/20/2009 12:12:04 PM

    Scusate se posto qui, ma avrei bisogno con urgenza vostre opinioni o collegamenti online che riguardino le best practices in relazine alla gestione della quota e all'archiviazione con LN 8.

    Abbiamo caselle che sfiorano i 6GB e stavamo attuando delle politiche di archviazione standard (sul pc locale e replica su un server Domino).

    Cosa mi consigliate? Quali sono le vostre best practices?

    Grazie infinite!!!

  • #2 Stefano Benassi 03/31/2009 10:13:24 PM

    Ci sono già passato. Ho 2 clienti sui quali ho dovuto rinominare il dominio Domino a causa del fatto che il BP che aveva installato il primo server aveva inserito un carattere assolutamente vietato (il ".") nel nome del dominio.

  • #3 Daniele Grillo 03/31/2009 8:23:44 PM

    Oggi a me invece chiama un cliente a cui dei bravissimi BP ( ignoranti e che non conoscono affatto Lotus Domino arrghhh) hanno creato un DOMAIN domino con la seguente sintassi

    "NOME AZIENDA S.P.A" ed oggi hanno problemi di routing interno..indovinate come mai????

    Questa non l'avevo mai vista!

  • #4 Francesco Pellegrini 03/30/2009 1:28:46 AM

    ...e quelli che, visto che usano iNotes e basta, hanno pensato bene di buttare via il cert.id (a cosa serve? via, via che fa disordine) e un bel giorno vogliono mettere in cluster il loro mail server....

    E quando gli spieghi il casino in cui si sono cacciati non ti credono e pensano che tu li stia prendendo in giro cercando di grassargli dei soldi per una consulenza?

    Vai Mere, vuol dire che ci sono tante aziende che hanno bisogno di una mano competente.... prima o poi arriveranno tutti....

  • #5 Roberto Boccadoro 03/27/2009 2:07:26 PM

    Bè, leggetevi questo in aggiunta a quanto dice Mere....

    { Link }

    Nessun commento da fare :-)

    RoB

  • #6 Sandro Pernasili 03/26/2009 11:29:42 AM

    Ho visto cose che voi umani non potreste neanche immaginare: intere Domino Directory con utenti (migliaia) rinominati a mano sui records persona dei server e IDs Notes disperati che continuavano a collegarsi cercando la propria identità (oltre alla chiave pubblica :) , Domino Directory replicate sui clients senza neppure la forzatura di una replica coerente delle ACLs (così i notebook potevano indirizzare la posta offline), servers 5 con l'ODS della 4, Servers 6 e 7 con l'ODS della 5, servers 8 con ODS e modelli dei DBs della posta rigidamente 6 (massimo 7), E tutti costoro erano convinti di aver upgradato correttamente...

    Ho visto Names pubblicate su internet con gli IDs amministrativi appesi sotto i records persona (con admin come PWD dell'admin e la 1352 pubblicata, giuroooooooo.....) . Ho visto intere directory con migliaia di utenti create senza gli IDs (tanto inizialmente avevano scelto di usare l'IMAP come protocollo...), ho visto DBs nascere dalla 4 e diventare dei mostri perchè lo sviluppatore di turno ci aggiungeva la vista o il form che gli faceva comodo e negli anni arrivare alla 7 sfondando tranquillamente la soglia dei 20 GB (molti anche molto più grandi) ingaggiare sanguinose battaglie con l'Update e l'Updall . Ho visto servers rinominati "ad capocchiam" urlare sul log che non trovavano la loro chiave pubblica (molti li ho curati). Ho visto uomini che si erano resi colpevoli o complici di questi crimini contro l'informatica asserire "Domino non vale un c., meglio passare ad Exchange"...

    ...e tutti quei momenti andranno perduti nel tempo...

    come lacrime nella pioggia.

    :D :D :D

    Bel post, complimenti ;)

  • #7 Iarin Fabbri 03/26/2009 8:42:12 AM

    OT anche io.

    Complimenti anche da parte mia.

    PS: invece di sparare a 0 su noi programmatori quali cause di riduzione delle performance, vieni a programmare anche tu ;-))))

  • #8 Claudio "CaioZ" 03/25/2009 9:29:08 PM

    vado un po' OT ma non potevo che complimentarmi per il post ... grande Mere ;)

    per le ns esperienze passate aggiungerei alle bestialita' da evitare anche la sincronizzazione "manuale" tra diversi server di gruppi e utenze ...

  • #9 Matteo Bisi 03/25/2009 9:06:35 PM

    vietato fare switch id sul client leggero del server con il file id di un utente di un altra organizzazione

    sul mailsever aziendale quando è acceso ... potrebbe andare in panic...( ed avrebbe pure ragione)

Commenta articolo
 

Questo spazio web è stato creato da per un uso pubblico e gratuito. Qualsiasi tipo di collaborazione sarà ben accetta.
Per maggiori informazioni, scrivete a info@dominopoint.it

About Dominopoint
Social
Dominopoint social presence: