Cluster 2008 – Accesso alle share e Interoperabilità con altri Sistemi Operativi

Ultimamente mi capita sempre più spesso di lavorare su problemi di apparente incompatibilità tra i client Apple e il failover Cluster 2008. Lo scenario più ricorrente, è costituito da un client Apple che riesce ad accedere a tutte le share esposte attraverso un cluster 2003, mentre allo stesso tempo fallisce su qualsiasi share pubblicata attraverso un cluster 2008.

Questo comportamento è dovuto all’introduzione del “File Share Scoping” nel cluster 2008. Questa nuova caratteristica aggiunge ad ogni share uno “scope”, ovvero ne restringe l’uso solamente attraverso il nome con la quale è stata pubblicata all’interno del cluster.

Per capire meglio, dobbiamo fare il paragone con il cluster 2003, in cui è possibile accedere alle risorse condivise in diversi modi:

• \\NOME-RISORSA-CLUSTER
• \\IP-RISORSA-CLUSTER
• \\NOME-NODO-FISICO
• \\IP-NODO-FISICO
• \\CNAME (alias)

Tutti i modi sopra elencati sono equivalenti in quanto producono lo stesso risultato: elenco di tutte le cartelle condivise del nodo attivo. È interessante notare che nell’elenco restitutito compaiono anche tutte le share locali e non clusterizzate presenti sul nodo fisico.

Un cluster 2008, a differenza, non restituisce tutte le share presenti sul nodo, ma solamente quelle nello scope del nome utilizzato:

Quindi l’unico modo lecito per accedere ad una share, su di un cluster 2008, è quello di specificare esattamente il nome della risorsa clusterizzata nel path UNC. L’accesso alla share tramite l’indirizzo IP, seppur clusterizzato, non è quindi più consentito.

Per altre informazioni sul “File Share Scoping” potete fare riferimento a questo altro articolo.

Fatta questa breve ma doverosa introduzione, vediamo perchè i client Apple falliscono nell’accesso alle share condivise del cluster 2008.

Generalmente il comando utilizzato dal client richiede il path UNC al quale connettersi:

“smb://NOME-RISORSA-CLUSTER ”

Analizzando le traccie di rete possiamo notare che il nome della risorsa viene tradotto nell’indirizzo IP clusterizzato:

+ Nbtss: SESSION MESSAGE, Length =95
- Smb: C; Tree Connect Andx, Path = \\192.168.1.100\FS Service = A:
Protocol: SMB
Command: Tree Connect Andx 117(0x75)
+ NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS,
Code = (0) STATUS_SUCCESS
+ SMBHeader: Command, TID: 0xFFFF, PID: 0x0001, UID: 0x0802, MID: 0x0008
- CTreeConnectAndX:
WordCount: 4 (0x4)
ANDXCommand: No Secondary Command 255(0xFF)
AndXReserved: 0 (0x0)
ANDXOffset: 0 (0x0)
+ Flags: Retain Tree connection to Tid, No extended security
PasswordLength: 1 (0x1)
ByteCount: 52 (0x34)
Password:
+ Path: \\192.168.1.100\FS
Service: A: - Disk share for PC NETWORK PROGRAM 1.0 or later

Questo è esattamente il motivo del fallimento, infatti come abbiamo visto una richiesta fatta tramite l’IP clusterizzato, restituisce l’elenco delle share locali al nodo, invece che l’elenco delle share clusterizzate. Non trovando la risorsa richiesta, il client fallisce la sua esecuzione.

Per ovviare al problema, alcuni nostri clienti hanno risolto utilizzando i seguenti comandi, che a quanto pare a livello SMB non traducono il nome della risorsa nel suo indirizzo IP:

"smb:// NOME-RISORSA-CLUSTER :139/NOME_SHARE$"
"cifs:// NOME-RISORSA-CLUSTER :139/NOME_SHARE$"

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platform Support