Archivi categoria: STandard

OpenContainerInitiative: finalmente uno standard per la trasmissione di immagini dei container

Facebooktwittergoogle_plusredditlinkedin

Due anni fa parlavamo della nascita della Open Container Initiative sotto il controllo della Linux Foundation. Con l’esplosione dell’uso dei container, e delle tecnologie in grado di gestirli, definire uno standard ufficiale ed aperto per la creazione, l’esecuzione e la trasmissione delle immagini dei container è diventato fondamentale.

E, finalmente, si inizia ad arrivare a qualcosa di completo: già in passato il formato delle immagini ed i runtime sono stati standardizzati dalla OCI, che l’anno scorso ha raggiunto una maturità con il rilascio della versione 1.0; in questi giorni il lancio del progetto Distribution Specification ha definito lo standard anche per il push e pull delle immagini (le operazioni utilizzate per caricare e scaricare le immagini da un registro), andando così a coprire (quasi) tutto il mondo container: come viene creato, come viene eseguito e come viene trasmesso.

Per questa operazione hanno deciso di basarsi sulla definizione del Docker Registry V2; essendo questo un registry dei più utilizzati al mondo (forse il più utilizzato), è sembrato logico prendere le specifiche di come lavorasse e, sulla base di quelle, costruire uno standard che, tendenzialmente, permetterà l’adozione dalla maggior parte dei sistemi di gestione di container senza grosse modifiche.

Ovviamente Docker non può che essere contenta del fatto che la sua implementazione è diventata lo standard, come affermato da Michael Crosby, ingegnere e maintainer in Docker:

Docker’s contribution of the Docker Registry V2 specification aligns with our history of making key open-source projects available to the community. As with the runtime and image specification, Docker’s registry protocol has become a de facto standard with over 40 billion images pulled using this protocol.

Il contributo di Docker alle specifiche del Docker Registry V2 si allinea con la nostra abitudine storica di rendere i progetti open-source chiave disponibili alla community. Insieme al runtime ed alle specifiche delle immagini, il registry protocol di Docker è diventato lo standard de facto con oltre 40 miliardi di immagini scaricate usando questo protocollo.

La notizia in ogni caso è stata accolta molto positivamente da tutti, sia da Amazon con il suo Amazon Elastic Container Registry (che comunque è compatibile con il Docker Registry V2), sia da Microsoft che eroga l’Azure Container Registry (implementato usando proprio il Docker Registry) che Google, fornitore di Google Cloud (di cui non si sa molto riguardo il funzionamento dei registry forniti).

Tutti contenti dunque, abbiamo uno standard completo!
Ora non resta che aspettare che tutti lo abbraccino.

Windows Server 2016 – Quali sono le differenze tra la Standard Edition e la Datacenter Edition

Facebooktwittergoogle_plusredditlinkedin

Anche Windows Server 2016, come Windows Server 2012/2012R2, verrà rilasciato in due versioni: Standard e Datacenter.

Mentre in Windows Server 2012/2012R2 non c’era differenza tra le funzionalità offerte dalle due versioni del sistema operativo, in Windows Server 2016 saranno introdotte delle differenze, che vi riassumo nella tabella:

Edizioni di Windows Server 2016

Standard

Datacenter

Funzionalità di base

SI

SI

Macchine virtualiHyper-V Containers

2

Illimitati

Windows Server Containers

Illimitati

Illimitati

Nano Server

SI

SI

Storage Spaces Direct / Storage Replica

NO

SI

Shielded VM / Host Device Guardian

NO

SI

New Networking Stack

NO

SI

Come si può notare dalla tabella le differenze tra le diverse versioni riguardano alcune funzionalità Azure-inspired dello Storage e del Networking.

Altra cosa da tenere in considerazione è la modifica al Pricing and Licensing delle due versioni. Come infatti riportato nel documento Windows Server 2016 and System Center 2016 Standard and Datacenter Editions Pricing and licensing FAQ di Dicembre 2015, Windows Server 2016 non sarà più licenziato per socket ma per core fisico (senza hyper-threading).

In Windows Server 2012 R2 infatti avevate bisogno di una licenza di Windows Server ogni 2 socket fisici, per un massimo di 16 core.

In Windows Server 2016 dovrete:

  • Licenziare tutti i core fisici del server
  • Licenziare un minimo di 8 core per ogni processore fisico
  • Licenziare un minimo di 16 core per ogni server
  • Acquistare le licenze in pacchetti da 2

Nel documento è anche riportato un esempio di quanti pacchetti da 2 licenze acquistare in base ai core fisici disponibili sul server:

Figura 1: Numero di pacchetti di licenze da acquistare

È bene ricordare che andranno licenziati solo i core fisici e non quelli “virtuali” abilitati tramite l’hyper-threading e solo quelli realmente disponibili. Infatti in quasi tutti i server è possibile disabilitare da BIOS la disponibilità dei core o dei processori fisici.

Rimane cmq valida la necessità di acquistare le CAL per i client che si connettono a Windows Server, come nelle versioni precedenti.

Per quanto riguarda Nano Server, essendo una modalità di installazione e non una versione diversa del sistema operativo, dovrà essere licenziata esattamente con i parametri precedentemente indicati.

Maggiori informazioni sono disponibili nel Windows 2016 licensing datasheet pubblicato da Microsoft.

DocumentDB riceve la certificazione ISO 27100

Facebooktwittergoogle_plusredditlinkedin

Il team di Azure ha annunciato che DocumentDB ha ricevuto la certificazione ISO 27001, HIPAA e la EU Model Clauses. La certificazione ISO 27001 è uno standard che garantisce la sicurezza delle informazioni e ne esplicita il controllo di gestione. Attualmente è una delle certificazioni più ampiamente riconosciute per i servizi cloud e porta un valore aggiunto alla famiglia dei servizi di Azure.

Oltre alla certificaazione ISO, DocumentDB è certificato per l’EU Model Clauses e ha raggiunto anche l’attestazione HIPAA (Health Insurance Portability and Accountability Act). Quest’ultima stabilisce i requisiti per l’utilizzo, la divulgazione e la salvaguardia delle informazioni sanitarie individualmente indentificabili mentre la EU Model Clauses garantisce che i dati vengano gestiti all’interno del territorio europeo nel rispetto del diritto alla protezione dei dati sancito dall’Unione Europea.

Queste certificazioni possono agevolare l’utilizzo dei servizi di Azure in territorio Europeo e permettere ai clienti di investire in ambiti di intervento dove gli standard sono requisiti fondamentali. Il team di Azure ha confermato di essere al lavoro per raggiungere ulteriori conformità e ampliare i livelli di standard.

Link: Guida per testare DocumentDB

Precisazioni sul licensing della suite System Center 2012

Facebooktwittergoogle_plusredditlinkedin

Per mia personale scelta, non approfondisco mai troppo il licensing dei prodotti Microsoft, per le seguenti motivazioni :

  • frequente complessità
  • frequenti diverse condizioni di licensing a seconda del tipo di contratto stabilito dall’azienda con Microsoft
  • documenti ufficiali Microsoft spesso non precisi, o riportanti solo una-due casistiche generali, senza cenni o esempi riguardanti casi particolari in cui potrebbero ritrovarsi certe aziende
  • vendor di licenze Microsoft che spesso danno informazioni di Licensing in contrasto l’un con l’altro

A questo punto, mi sono sempre riproposto di approfondire veramente il licensing Microsoft solo se “obbligato” a farlo, per esempio quando ho la responsabilità di un progetto per un cliente, che mi chiede l’approfondimento, oltre che della parte tecnica, anche della parte relativa ai costi di implementazione.

Poi capita che, durante corsi o seminari vari, si instaurino discussioni che fanno sorgere dubbi e/o perplessità ai partecipanti, e anche a me stesso :-) , devo dire…

Uno degli ultimi dubbi si è creato riguardo la suite di prodotti System Center 2012.  Allora mi sono sentito in dovere di approfondire i concetti, e cercherò ora di illustrarvi le conclusioni con parole semplici (e non in geroglifico, come spesso capita sui documenti MS) e con qualche esempio pratico.

Concetti fondamentali del Licensing della Suite System Center 2012 SP1

Il Licensing della Suite è suddiviso in due parti : “Server Management Licensing” e “Client Management Licensing”.

Di seguito nell’articolo, utilizzerò le seguenti terminologie :

“Server ML” : Server Management Licensing

“Client ML” : Client management Licensing

“Server OSE” : Server Operating System Environment, cioè sistema operativo server (es. Windows Server 2008 R2)

“PSOSE” : Physical Server Operating System Environment, cioè sistema operativo server (es. Windows Server 2008 R2) installato su un host fisico

“VSOSE” : Virtual Server Operating System Environment, cioè sistema operativo server virtualizzato (es. Windows Server 2008 R2) installato in una macchina virtuale

“Client OSE” : Client Operating System Environment, cioè sistema operativo client (es. Windows 7)

Server Management Licensing (Server ML)

  1. Sono richieste licenze “Server ML” solo per i “server gestiti” di tipo PSOSE o VSOSE : vuol dire che non si pagano licenze “Server ML” per i server dove si installano i componenti della suite, ma solo per i server che vorremo gestire attraverso la suite System Center.   (N.B. : se i server con le applicazioni System Center sono a loro volta “server gestiti”, allora per essi sono necessari le licenze “Server ML”)
  2. Le licenze “Server ML” sono disponibili in due edizioni : “Standard” e “Datacenter”.  Entrambe danno diritto ad utilizzare tutti i componenti della suite, e differiscono solo per il numero di “VSOSE” che permettono di gestire.  La Standard permette di gestire fino a 2 “VSOSE”, la Datacenter illimitati “VSOSE”
  3. E’ sempre compresa nel prezzo la licenza che dà diritto ad eseguire un’istanza di SQL Server Standard, purchè questa supporti unicamente i prodotti della suite System Center.   Se si installano multiple istanze SQL su più server, sono tutte comprese nel prezzo (purchè siano sempre ad utilizzo esclusivo dei prodotti System Center)
  4. Le licenze “Server ML” sono “per processore”, con ogni licenza in grado di coprire fino a due processori fisici.  Cosa vuol dire?  Ecco alcuni esempi :
    • Per gestire 1 PSOSE bi-processore, occorre una licenza “Standard Server ML” oppure una licenza “Datacenter Server ML”
    • Per gestire 1 PSOSE quadri-processore, occorono due licenze “Standard Server ML” oppure due licenze “Datacenter Server ML”
    • Per gestire 5 PSOSE bi-processore, occorrono cinque licenze “Standard Server ML” oppure cinque licenze “Datacenter Server ML”
    • Per gestire 5 PSOSE quadri-processore, occorrono dieci licenze “Standard Server ML” oppure dieci licenze “Datacenter Server ML”
  5. In base al precedente punto 4, sembrerebbe quindi che sia sempre conveniente comprare le “Standard Server ML” (che effettivamente costano meno delle “Datacenter Server ML”).  In realtà non è sempre così.  Nel punto 4 si è parlato solo della gestione di server fisici (PSOSE), e qui la regola è abbastanza semplice : su ogni PSOSE, si conta il numero dei processori, si divide per due, si arrotonda per eccesso (per es. se il numero risultante è dispari) e si ottiene il numero di licenze “Server ML” necessarie per quel server (Standard o Datacenter, in questo caso, non fa differenza).  Ora, dal punto 6, parliamo anche della gestione di server virtualizzati (VSOSE) sopra uno o più host fisici
  6. Come detto al punto 2, una licenza “Standard Server ML”, assegnata ad un PSOSE, permette di coprire la gestione di 2 VSOSE (virtualizzati su quel PSOSE).  Invece, una licenza “Datacenter Server ML”, assegnata ad un PSOSE, permette di coprire la gestione di infiniti VSOSE (virtualizzati su quel PSOSE).
  7. “Standard Server ML” : per calcolare quante ne servono per coprire la gestione di un PSOSE + n VSOSE, usare una delle seguenti regole :
    • Se il PSOSE è utilizzato per eseguire software e servizi di virtualizzazione e anche per altri scopi, contare il numero di processori fisici del PSOSE e il numero di VSOSE presenti : tra i due conteggi, tenere buono il più alto e dividere per due : quello è il numero di “Standard Server ML” necessarie per quel PSOSE
    • Se il PSOSE è utilizzato solo per eseguire software e servizi di virtualizzazione, contare solo il numero di VSOSE presenti, e dividere per due : quello è il numero di “Standard Server ML” necessarie per quel PSOSE
    • Esempio :
    • se abbiamo 16 PSOSE quadri-processore, usati come server di virtualizzazione + altri scopi, ognuno con 12 VSOSE, eseguo i seguenti conteggi :
      • numero totale di processori : 16 X 4 = 64
      • numero totale di VSOSE : 16 X 12 = 192
      • tra i due conteggi, il più alto è il numero di VSOSE (192)
      • divido per due e ottengo il numero di “Standard Server ML” necessarie : 192 / 2 = 96
  8. “Datacenter Server ML” : per calcolare quante ne servono per coprire la gestione di PSOSE + VSOSE, contare semplicemente il numero di processori presenti sul/sui PSOSE
    • Esempio :
    • se abbiamo 16 PSOSE quadri-processore, usati come server di virtualizzazione + altri scopi, ognuno con 12 VSOSE, eseguo il seguente conteggio :
      • numero totale di processori : 16 X 4 = 64
      • divido per due e ottengo il numero di “Datacenter Server ML” necessarie : 64 / 2 = 32
  9. Confrontando gli esempi dei punti 6 e 7, si nota come in questo caso il numero di licenze Datacenter richiesto sia notevolmente inferiore (e di conseguenza pure il costo totale)

La seguente tabella esemplificativa potrà essere utile per rapidi calcoli :

tab.jpg      Clicca per ingrandire

Client Management Licensing (Client ML)

  1. Sono richieste “Client ML” per ogni dispositivo gestito che sia un “Client OSE” (es. Windows XP, Windows 7…)
  2. Ci sono 3 tipi di “Client ML” disponibili :
    • System Center 2012 Configuration Manager Client ML
      • copre (per user o per OSE) gli agent di Configuration Manager e Virtual Machine Manager
    • System Center 2012 Endpoint Protection Client Subscription License (SL)
      • copre la sottoscrizione (per user o per device) agli aggiornamenti antimalware di Endpoint Protection
    • System Center 2012 Client Management Suite Client ML
      • copre (per user o per OSE) gli agent di Service Manager, Operations Manager, Data Protection Manager, Orchestrator
  3. E’ possibile utilizzare la “Core CAL Suite” :
    • comprende “System Center 2012 Configuration Manager Client ML” e “System Center 2012 Endpoint Protection Client Subscription License (SL)”
  4. E’ possibile utilizzare la “Enterprise CAL Suite” :
    • comprende tutti i tre tipi di System Center 2012 Client MLs

Share/Bookmark

Roadmap dei prodotti Microsoft : aggiornamento Luglio 2012

Facebooktwittergoogle_plusredditlinkedin

Le maggiori novità di Luglio sono ancora su Windows 8 e Windows Server 2012.

E’ stata annunciato che, per entrambi, la versione RTM sarà pronta già per la prima settimana di agosto, quindi in anticipo rispetto alle previsioni.

I primi a ricevere la versione RTM saranno ovviamente OEM e System Builders.

La GA (General Availability) al pubblico è prevista invece per settembre, attraverso diversi canali di vendita.

Windows Server 2012

Sono state annunciate anche le edizioni che saranno disponibili per Windows Server 2012.

Saranno solo 4 : Datacenter, Standard, Essentials, Foundation.

La notizia principale è quindi il ritiro dell’edizione “Enterprise”, finora sempre presente nelle piattaforme 2000, 2003 e 2008 : tutte le caratteristiche della Enterprise Edition saranno ora incluse nella Standard Edition (compreso il Failover Cluster :-) ).

Oltre alla Enterprise, saranno ritirate anche le edizioni “Web” e “HPC” : per gli utenti di HPC Edition, è disponibile dal 7 giugno 2012 un “HPC Pack” che permetterà di continuare ad utilizzare i tipici carichi di lavoro di un ambiente HPC.  Ecco il link per il download :

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=6535

Saranno dismesse anche le piattaforme “Small Business Server” (SBS) e “Home Server” (WHS) : SBS 2011 sarà quindi l’ultimo della serie!  Secondo Microsoft, le piccole aziende sceglieranno sempre di più l’adozione di soluzioni cloud per appoggiare i propri servizi di posta, backup e gestione documenti : quindi SBS tenderebbe a subire un drastico calo di vendite.  SBS 2011 rimarrà comunque acquistabile tramite canale OEM fino al 31 dicembre 2013 e tramite tutti gli altri canali di vendita fino al 30 giugno 2013.

Il sostituto di SBS sarà Windows Server 2012 Essentials Edition : avrà un limite di 25 utenti ed un costo (per ora indicato solo in dollari) di $ 425. 

Windows Server 2012 Essentials conterrà un setup molto facilitato, una gestione semplificata dello storage, del backup e del recupero da cancellazioni accidentali di files, la tecnica “Anywhere Access” per garantire un collegamento costante alle applicazioni anche da remoto, un monitoraggio integrato di sè stesso e dei client Windows 7, Windows 8 e MAC OS X della rete.

Chi possiede SBS 2011 con Software Assurance, avrà diritto ad una licenza di Windows Server 2012 Standard e ad una di Exchange 2010 Standard.  Non sarà più disponibile il Premium Add-On di SBS 2011.

In definitiva, ecco le caratteristiche fondamentali delle 4 edizioni di Windows Server 2012 :

Datacenter Edition : contiene tutte le features, illimitate istanze virtuali, modello di licensing “per processore + CAL”, costo di circa $ 4800

Standard Edition : contiene tutte le features, due istanze virtuali, modello di licensing “per processore + CAL”, costo di circa $ 880

Essentials Edition : features limitate e supporto fino a 2 processori, modello di licensing “per server con limite a 25 utenti, CAL non richieste”, costo di circa $ 425

Foundation Edition : features limitate e supporto per un solo processore, modello di licensing “per server con limite a 15 utenti, CAL non richieste”, disponibile solo tramite canale di vendita OEM

Ecco il link per il download di un datasheet maggiormente esplicativo del nuovo modello di licensing :

http://download.microsoft.com/download/0/4/B/04BD0EB1-42FE-488B-919F-3981EF9B2101/WS2012_Licensing-Pricing_Datasheet.pdf

Buona consultazione….

Share/Bookmark

Elementi fondamentali di progettazione di un’infrastruttura Lync Server 2010

Facebooktwittergoogle_plusredditlinkedin

Lync Server 2010 è un prodotto che si integra con numerosi servizi di infrastruttura, software, protocolli e apparati di rete.  Per questo motivo la sua corretta progettazione riveste un’importanza fondamentale per ottenere il perfetto funzionamento di tutte le sue features.

Lo scopo di questo articolo è indicarvi quali sono i componenti fondamentali di un’infrastruttura Lync, a cosa servono, e come devono essere implementati e utilizzati.

Comincio col dire che, per progettare e poi gestire un’infrastruttura Lync, sarebbe molto utile avere :

  • Conoscenze di Active Directory, DNS e servizi di infrastruttura
  • Esperienza sulla precedente piattaforma OCS 2007 R2
  • Conoscenza di tecnologie correlate, come per esempio Exchange Unified Messaging
  • Conoscenze concettuali di tecnologie di telecomunicazione, tra cui :
    • TDM (Time Division Multiplexing) e integrazione con VoIP
    • Gateways e PBX (Private Branch eXchange)
    • Differenze tra “Signaling” e “Media”
    • SIP (Session Initiation Protocol) e H.323
    • Codecs
    • Normalizzazione dei Dial Plan

La conoscenza delle tecnologie di telecomunicazione è utile, oltre che per la fase di progettazione, anche per risolvere in futuro eventuali problemi di integrazione tra Lync e i vostri apparati di telecomunicazione.

Ecco i concetti fondamentali di progettazione da tenere presente.

Disponibilità di Lync Server 2010

E’ disponibile solo in edizione a 64 bit, e richiede un sistema operativo Windows Server 2008 SP2 Standard, Enterprise, Datacenter, oppure Windows Server 2008 R2 Standard, Enterprise, Datacenter. Tutti i ruoli di Lync richiedono uno dei suddetti sistemi operativi. I client, invece, non richiedono hardware o software a 64 bit.

Differenze tra Lync Server 2010 “Standard Edition” e “Enterprise Edition”

La Standard Edition è consigliabile per piccole aziende, tutte le sue features (compresi i database) risiedono su un unico server; dimensionando opportunamente il server, può arrivare a gestire anche 5000 utenze, ma non garantisce alta disponibilità.

La Enterprise Edition garantisce anche l’alta disponibilità delle features, richiede un minimo di due server nell’infrastruttura (il Front-End e il Back-End), è totalmente scalabile e può arrivare a supportare centinaia di migliaia di utenze!

Ruoli di Lync obbligatori

Il “Front-End Server” e il “Back-End Server” (nella Standard Edition sono sullo stesso server, nella Enterprise Edition sono due server diversi), e il “Audio/Video Conferencing Server”.

Ruoli di Lync opzionali

Edge Server, Mediation Server, Monitoring Server, Archiving Server, Director Server : da installare, sullo stesso server o su server diversi (o su pool di server diversi) a seconda delle necessità organizzative.

Ruolo “Front-End Server” (obbligatorio)

E’ il ruolo centrale e più importante di Lync 2010. In una Standard Edition si installa su un unico server (unitamente al ruolo Back-End), mentre in una Enterprise Edition si installa su un server (o un pool di servers, per la ridondanza) separatamente dal ruolo Back-End. Il Front-End Server ha diversi compiti :

  • gestire le registrazioni di presenza e di telefonia degli utenti (utilizzando il componente denominato “Registrar”)
  • fornire servizi di conferenza audio/video, conferenza Web, conferenza dial-in, condivisione applicazioni, chat
  • gestire il CMS (Central Management Store), che comunica i dati di configurazione a tutti i server Lync dell’infrastruttura
  • fornire aggiornamenti ai client Lync 2010

Ruolo “Back-end Server” (obbligatorio)

E’ rappresentato dal server (con un’installazione di SQL) che fornisce i servizi di database al ruolo Front-End.  In una Standard Edition è installato assieme al ruolo Front-End, in una Enterprise Edition deve per forza essere un server separato dal Front-End, con possibilità di utilizzare più server in cluster per ottenere ridondanza.   In effetti, il Back-End Server non esegue nessun servizio specifico di Lync, ma solo i servizi di database.  Nel database sono memorizzate parecchie informazioni, tra cui :

  • presenza degli utenti
  • liste dei contatti
  • dati inerenti le conferenze e la loro schedulazione

Ruolo “Audio/Video Conferencing Server” (obbligatorio)

E’ di solito collocato con il Front-End Server, ma può anche essere collocato in un pool di server separato per ottenere scalabilità e ridondanza.  Richiede molta potenza di processore per le aziende che usano ampiamente questo tipo di conferenze.

Le conferenze audio/video permettono le comunicazioni audio e video in diretta tra gli utenti, semprechè gli utenti siano dotati di opportuni dispositivi come le cuffie/microfono per le conferenze audio, e le webcam per le conferenze video.

Questo ruolo gestisce anche le conferenze Web, che danno la possibilità agli utenti di vedere, condividere e collaborare su documenti online, oppure di condividere i loro desktop o le loro applicazioni.

Ruolo “Edge Server” (opzionale)

Dovrebbe essere sistemato nella DMZ aziendale, ha il compito di gestire le connessioni esterne degli utenti remoti, degli utenti federati, degli utenti anonimi che devono partecipare a conferenze Web, e degli utenti che utilizzano sistemi di chat pubblici.  Non serve se non si vuole garantire l’accesso dall’esterno alle features di Lync.

Più nel dettaglio, ecco di cosa si occupa il ruolo Edge :

  • fornire servizi di accesso agli utenti esterni per quanto riguarda il “signaling SIP”, la presenza e la chat (servizio “Access Edge”)
  • fornire servizi di conferenza web (servizio “Web Conferencing Edge”)
  • fornire servizi audio/video, di condivisione desktop e applicazioni e di trasferimento files (servizio “A/V Edge”)

Si può utilizzare un pool di server Edge per ottenere ridonandaza, opportunamente integrati con soluzioni di DNS Load balancing o Hardware Load Balancing.

Ruolo “Mediation Server” (opzionale)

Può essere collocato con il Front-End Server su singola macchina, oppure su un pool di server separati dal FE.  E’ il ruolo essenziale per l’implementazione della parte VoIP (Enterprise Voice).  Non serve se non si implementa e utilizza il VoIP.

Il suo compito primario è quello di “transcodificare” il traffico di Signaling e, in alcuni casi, il traffico di Media tra l’infrastruttura VoIP interna e i Gateway PSTN o gli apparati PBX o i SIP Trunk utilizzati per accedere alla rete PSTN pubblica.

Può essere configurato in diversi modi a seconda della topologia di rete aziendale, degli apparati di telecomunicazione presenti e del tipo di uscita verso la rete PSTN pubblica.

Ruolo “Director” (opzionale)

Ha il compito di autenticare utenti interni ed esterni, redirezionandoli al corretto pool di server.  E’ utile se l’azienda ha implementato diversi pool nell’infrastruttura (quindi solo per aziende di grosse dimensioni), garantendo anche l’accesso dall’esterno agli utenti.   Se implementato, toglie ai pool di server Front-End il sovraccarico di lavoro per eseguire le autenticazioni, e questo migliora le performance : in questo caso tutte le richieste di accesso fluiscono prima verso il Director, che poi ne esegue il routing verso il corretto pool di Front-End.

Il Director è sempre un server separato dal Front-End, e non collocato con altri ruoli Lync.  E’ possibile creare un pool di Directors per la ridondanza, a patto di implementare anche soluzioni di Load Balancing.

Ruolo “Monitoring Server” (opzionale)

Ha il compito di collezionare informazioni su QOE (Quality of Experience) e CDR (Call Details Record).  Richiede la presenza di database che usino SQL Server : questi possono essere collocati sul Monitoring Server stesso, o su server differenti.  Se si decide di utilizzare anche la reportistica, bisogna prevedere la presenza anche di SQL Server Reporting Services.

Il Monitoring Server non può essere collocato con il Front-End.  Può invece essere collocato assieme all’Archiving Server : in questo caso, i loro database possono essere collocati sul server stesso, oppure separati su differenti server.   Il server che ospita i database del Monitoring Server può anche ospitare altri database utilizzati da altri tuoli di Lync, oppure database utilizzati da prodotti di terze parti.

Ruolo “Archiving Server” (opzionale)

Ha il compito di archiviare i messaggi di chat e le conferenze, specificando per quali utenti è abilitata l’archiviazione.

Si può abilitare l’archiviazione per comunicazioni tra utenti interni, o tra interni ed esterni.

Alcuni tipi di contenuto non sono archiviabili :

  • trasferimenti di files peer-to-peer
  • condivisione di applicazioni
  • annotazioni e sondaggi nelle conferenze

Per la collocazione dell’Archiving Server, valgono le stesse regole del Monitoring Server.

Cosa sono i “Siti” in Lync Server 2010 e come bisogna progettarli

Generalmente, un “Sito” rappresenta una locazione geografica della rete aziendale. Più precisamente, possiamo definire “Sito” un insieme di computers ben connessi fra loro su una rete ad alta velocità e bassa latenza (per esempio una singola LAN, o due diverse LAN connesse da fibra ottica).

Segnalo subito che i Siti di Lync sono un concetto separato dai Siti di Active Directory o da quelli di Exchange.  I Siti di Lync non devono necessariamente corrispondere ai Siti di Active Directory.

La prima cosa da definire progettando Lync, è il posizionamento del o dei “Central Site” e degli eventuali “Branch Sites”.

I “Central Sites” devono contenere il ruolo “Front-End Server”, che fornisce i servizi Lync essenziali : si può scegliere se installare un unico server Standard Edition, oppure un Pool di servers, che rappresenteranno il cosiddetto “Front-End Pool” (questo per questioni di ridondanza).  Ci deve essere per forza almeno un Central Site.  Il Central Site è tipicamente una locazione in cui esiste un datacenter e in cui ci siano persone IT esperte per la gestione.  Si possono creare anche diversi Central Site.

I “Branch Sites” possono essere assenti dalla topologia (per esempio chi non ha nessuna sede esterna), oppure essere presenti in gran numero.  Ogni Branch Site deve essere “affiliato” con un (e solo un) Central Site, in relazione padre-figlio.  Gli utenti presenti nel Branch Site ricevono i servizi Lync dai server presenti nel loro Central Site “padre”.   I Branch Site sono quindi consigliati per le sedi esterne e di ridotte dimensioni dell’azienda, dove probabilmente latita anche il personale IT esperto per la gestione.

In un Branch Site si può prevedere la presenza, a scelta, dei seguenti dispositivi :

  1. Un “Survivable Branch Appliance” (SBA) : è un nuovo dispositivo introdotto in Lync Server 2010.  Si tratta di un Blade Server, con pre-installati dal vendor Windows Server 2008 R2 e i servizi di Registrar e di Mediation di Lync Server 2010; inoltre contiene un PSTN Gateway. L’SBA è progettato per siti contenenti da 25 a 1000 utenze
  2. Un “Survivable Branch Server” (SBS) : è un nuovo dispositivo introdotto in Lync Server 2010. Si tratta di un regolare server che esegue Windows Server 2008 R2, anch’esso con i componenti Registrar e Mediation di Lync installati. Deve connettersi ad un PSTN Gateway oppure ad un SIP Trunk stabilito con un provider di servizi di telefonia (ITSP). L’SBS è progettato per siti contenenti da 1000 a 5000 utenze
  3. Un semplice PSTN Gateway e, opzionalmente, un Mediation Server

Per Branch Sites dove non esiste ridondanza del collegamento di rete verso il sito centrale, è indicato il deploy di SBA o SBS (le precedenti opzioni 1 e 2), che forniscono ridondanza in caso di interruzione del collegamento WAN : per esempio, gli utenti possono ancora fare e ricevere chiamate VoIP anche senza il collegamento al sito centrale.

Per Branch Sites con le linee WAN già ridondate, è utile la terza opzione : si possono connettere al sito centrale con il PSTN Gateway, ed opzionalmente possono anche usare il Mediation Server.

Share/Bookmark