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ù ;)
Vademecum dell’Amministratore Domino
- 03/26/2009
- 9 commenti
9 Commenti:
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!!!
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.
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!
...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....
Bè, leggetevi questo in aggiunta a quanto dice Mere....
{ Link }
Nessun commento da fare :-)
RoB
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 ;)
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 ;-))))
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 ...
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)