Resilienza delle applicazioni: mantieni disponibili le app di Windows

Introduzione

Le applicazioni Windows spesso dipendono da molto più del server che le ospita. Database, servizi di identità, archiviazione, gateway, reti e punti finali degli utenti possono influenzare se un'applicazione rimane utilizzabile durante un'interruzione. Questo articolo spiega come i team IT possono valutare tali dipendenze, progettare resilienza attorno alle applicazioni Windows esistenti, monitorare i livelli giusti e testare se i piani di recupero preservano effettivamente le funzioni aziendali su cui gli utenti fanno affidamento.

Cosa è la resilienza delle applicazioni?

La resilienza dell'applicazione è la capacità di un'applicazione e dell'infrastruttura circostante di continuare a fornire funzioni vitali durante un'interruzione e di recuperare in modo prevedibile dopo un guasto.

La perturbazione può essere piccola o grande, e le cause possono variare da guasti hardware o di sistema operativo, arresti anomali delle applicazioni, aggiornamenti non riusciti, interruzioni del database, interruzioni di rete, errori di autenticazione, esaurimento delle risorse, dipendenze non disponibili o incidenti di sicurezza.

Un'architettura resiliente riconosce che i guasti sono inevitabili e, invece di mirare a prevenire ogni incidente, le organizzazioni IT cercano di limitare l'impatto di ciascuno e stabilire procedure di recupero controllate per mantenere o ripristinare il servizio.

La resilienza dell'applicazione è più di un semplice tempo di attività del server

Un errore comune è utilizzare la disponibilità di un server come proxy per la disponibilità dell'applicazione, che gira sul server.

Affinché un'applicazione aziendale sia realmente disponibile, è necessario che un certo numero di componenti sia disponibile contemporaneamente:

Infrastruttura → Sistema operativo → Applicazione → Dipendenze → Percorso di accesso → Sessione utente → Processo aziendale

Un problema con qualsiasi elemento in questa catena può comportare la resa dell'applicazione effettivamente non disponibile.

Ad esempio, un server di applicazioni può essere sano mentre il suo database è inaccessibile. Un'applicazione pubblicata può funzionare correttamente, ma un guasto del gateway rende impossibile l'accesso ai dipendenti remoti. Gli utenti possono anche avviare con successo l'applicazione, ma essere impediti dal completare una transazione perché un servizio di licenza, file o backend non è disponibile.

La resilienza dell'applicazione, quindi, dovrebbe essere misurata in base alla capacità dell'utente di eseguire il compito aziendale necessario, piuttosto che sulla capacità di un server di rispondere a un controllo di disponibilità o di salute.

Perché la resilienza delle applicazioni è diversa per le applicazioni Windows?

Le pratiche moderne di resilienza si concentrano sempre più su applicazioni native del cloud, contenitori, microservizi e orchestrazione automatizzata. Sebbene questi siano approcci preziosi, non sono sempre applicabili a ogni organizzazione.

Molte organizzazioni hanno applicazioni legacy Windows per le attività aziendali che sono state sviluppate prima che le architetture cloud-native diventassero comuni. Il software ERP, le applicazioni contabili, le applicazioni di produzione, le applicazioni sanitarie, le applicazioni ingegneristiche e le applicazioni sviluppate internamente possono essere tutte critiche per le operazioni di un'organizzazione.

Ristrutturare queste applicazioni come microservizi può essere estremamente costoso, tecnicamente impegnativo o addirittura completamente impraticabile se l'organizzazione non controlla il codice sorgente.

In questi casi, potrebbe esserci un valore significativo nel rendere le operazioni attorno all'applicazione più resilienti, piuttosto che cercare di rendere l'applicazione stessa più resiliente. Pubblicazione delle applicazioni può far parte di questo approccio mantenendo le applicazioni Windows esistenti su un'infrastruttura centralizzata mentre si modifica il modo in cui gli utenti vi accedono. Ciò può includere modifiche all'infrastruttura che ospita l'applicazione, come l'eliminazione dei vincoli infrastrutturali, la creazione di host applicativi ridondanti, l'abilitazione di metodi di accesso alternativi e l'implementazione di procedure di recupero più reattive per l'host dell'applicazione.

In quale caso potrebbe fallire la disponibilità di un'applicazione Windows?

Costruire la resilienza dell'applicazione inizia con la scoperta dei componenti necessari per fornire con successo un'applicazione dai loro host agli utenti. Questo processo evidenzia i potenziali punti di guasto che possono compromettere un'intera applicazione.

Host delle applicazioni

Un'applicazione in esecuzione su un singolo server Windows ha un chiaro punto di guasto unico.

Problemi hardware, aggiornamenti di Windows, corruzione del sistema operativo, esaurimento delle risorse o guasti delle applicazioni possono interrompere ogni utente che dipende da quella macchina. Se le esigenze di disponibilità lo richiedono, possono essere messi in atto più host di applicazioni per ridurre la dipendenza da una singola macchina e fornire capacità quando un server diventa non disponibile.

Database, archiviazione e altre dipendenze

Molte applicazioni Windows dipendono da servizi esterni all'host dell'applicazione. Questi servizi possono includere:

• database SQL
• condivisioni di file
• server di licenza
• Active Directory
• Sistema dei nomi di dominio (DNS)
• certificati
• API
• middleware
• memoria di rete
• infrastruttura di stampa

Introdurre un secondo server applicativo fornisce una resilienza minima se condividono una dipendenza comune da database o archiviazione che non è disponibile. Diventa evidente che la mappatura delle dipendenze deve estendersi oltre l'infrastruttura applicativa visibile.

Autenticazione e Identità

Gli utenti non possono accedere a un'applicazione sana se l'infrastruttura di autenticazione necessaria non è disponibile.

I team IT devono identificare i servizi di identità su cui dipendono le loro applicazioni critiche e assicurarsi di avere piani di failover in atto per quando queste risorse non sono accessibili. Active Directory, piattaforme di identità cloud, servizi di autenticazione a più fattori (MFA) e gateway di autenticazione possono tutti essere utilizzati per fornire una catena di disponibilità per un'applicazione.

Rete e percorsi di accesso remoto

Per le applicazioni Windows centralizzate, la connettività tra gli utenti e l'ambiente applicativo rappresenta un altro possibile dominio di guasto.

Immaginiamo l'intera catena:

Dispositivo utente → Internet o LAN → gateway → host dell'applicazione → servizi backend

Un guasto in qualsiasi punto di questa catena può impedire agli utenti di svolgere il proprio lavoro anche se l'applicazione è in esecuzione correttamente. Particolarmente rilevante per le organizzazioni distribuite in cui l'applicazione può essere attiva e funzionante nel data center ma inaccessibile agli utenti in un'altra posizione.

Endpoint

La resilienza dell'applicazione non richiede necessariamente che la normale workstation di un utente sia disponibile.

Offrire agli utenti autorizzati i mezzi per accedere ad applicazioni ospitate centralmente da un dispositivo alternativo o tramite un browser può garantire l'accesso, se un laptop diventa non disponibile, un ufficio diventa inaccessibile o i dipendenti devono lavorare da una posizione diversa.

L'architettura di distribuzione delle applicazioni può essere un componente di una strategia di continuità aziendale più ampia.

Qual è il processo per costruire la resilienza delle applicazioni per le app Windows?

Nessuna singola tecnologia rende l'applicazione resiliente. I team IT devono invece ridurre il numero di guasti che possono compromettere completamente una funzione e prepararsi a meccanismi di recupero controllati per quelli che rimangono.

1. Identificare le applicazioni critiche e i processi aziendali

Non tutte le applicazioni richiedono lo stesso grado di protezione. Inizia determinando quali applicazioni supportano le operazioni principali, su quali utenti si basano e la loro tolleranza ai tempi di inattività.

Due obiettivi di recupero traducono i requisiti aziendali in specifiche tecniche. Linee guida per la pianificazione delle contingenze del NIST definisce l'Obiettivo di Tempo di Recupero (RTO) e l'Obiettivo di Punto di Recupero (RPO) come parametri chiave per determinare i requisiti di recupero:

• Obiettivo di Tempo di Ripristino (RTO): una durata di inattività accettabile prima che il servizio venga ripristinato.
• Obiettivo di Recupero (RPO): un intervallo di perdita di dati accettabile, misurato nel tempo.

Un'applicazione utilizzata intensamente per elaborare ordini può avere un RTO di minuti, mentre un'applicazione di reporting finanziario eseguita una volta a settimana può permettersi giorni di inattività.

RTO e RPO definiscono il tipo di protezione necessaria per un'applicazione: failover istantaneo, ripristino rapido dei servizi o semplicemente una procedura di recupero documentata.

2. Mappa l'intera catena di dipendenza dell'applicazione

Documenta tutto ciò che deve esserci affinché l'applicazione svolga il suo lavoro.

Non fermarti all'eseguibile o al server Windows. Non dimenticare i database, lo storage, l'autenticazione, il DNS, il networking, i certificati, i sistemi di licenza, i gateway e i servizi esterni.

Per ciascuno, chiedi:

Cosa succede all'applicazione se questo scompare?

Questo esercizio metterà in evidenza punti di guasto singoli nascosti e stabilirà la sequenza di recupero. Ripristinare prima un host dell'applicazione non aiuta molto se il suo database, servizio di identità o archiviazione non sono ancora disponibili.

3. Rimuovere i punti critici di singolo fallimento

Una volta stabilito l'albero delle dipendenze, determinare quali componenti devono essere resi ridondanti, in base all'importanza aziendale e agli obiettivi di recupero.

Nel caso della distribuzione di applicazioni Windows, questo potrebbe comportare il dispiegamento di diversi server di applicazione piuttosto che fare affidamento sulle capacità di un singolo host. Con uno strato di bilanciamento del carico, le sessioni possono essere distribuite tra le istanze delle applicazioni durante le operazioni normali. In caso di guasto di un host, le connessioni in arrivo possono essere instradate verso istanze di server di applicazione funzionanti.

La pianificazione della ridondanza dovrebbe essere informata dall'analisi delle dipendenze, tuttavia. Più server applicativi che accedono a un singolo database critico, gateway di rete o livello di archiviazione presentano comunque un singolo punto di guasto.

La progettazione ad alta disponibilità deve quindi considerare il servizio applicativo come un'entità integrata. Per gli ambienti Windows Server che richiedono ridondanza a livello di infrastruttura, Documentazione del clustering di failover di Microsoft fornisce ulteriori indicazioni sulle topologie ad alta disponibilità e di ripristino da disastri.

4. Separare le applicazioni dai singoli endpoint

Installare un'applicazione critica direttamente su ogni workstation dei dipendenti può creare un diverso tipo di problema di resilienza. Se gli utenti perdono l'accesso al loro computer abituale, potrebbero anche perdere l'accesso alle applicazioni di cui hanno bisogno per continuare a lavorare.

Centralizzare le applicazioni su host Windows gestiti e presentare l'interfaccia dell'applicazione agli utenti elimina questo rischio. I dati e lo stato dell'applicazione sono memorizzati sull'host Windows gestito e accessibili da endpoint autorizzati.

Facendo ciò, rendiamo l'applicazione disponibile agli utenti anche se cambiano dispositivo o posizione. Sebbene la centralizzazione delle applicazioni non elimini i problemi infrastrutturali, aiuta a spostarla in un ambiente in cui può essere controllata dall'IT.

5. Fornire più di un metodo di accesso pratico

La resilienza può essere raggiunta evitando una dipendenza inutile da un singolo tipo di endpoint o metodo di connessione.

A seconda dell'architettura di distribuzione delle applicazioni, gli utenti possono utilizzare diversi accesso remoto metodi, inclusi un client compatibile con RDP, un avviatore di applicazioni dedicato, un portale web o una sessione browser HTML5.

I metodi di connessione alternativi non devono essere confusi con la ridondanza dell'infrastruttura. Se tutti si affidano allo stesso server guasto, l'applicazione è comunque non disponibile.

Forniscono resilienza all'accesso quando un'interruzione colpisce il dispositivo normale di un utente, il client installato o la posizione piuttosto che il servizio dell'applicazione stesso.

6. Monitora prima che il degrado diventi un'interruzione

La resilienza delle applicazioni non riguarda solo il recupero, ma una rilevazione tempestiva può evitare il degrado in un'interruzione.

Indicatori utili negli ambienti delle applicazioni Windows sono l'utilizzo della CPU, la pressione della memoria, la capacità del disco e I/O, l'utilizzo della rete, le sessioni attive, il processo dell'applicazione, il tempo di risposta, la connessione fallita e la disponibilità dei servizi dipendenti.

Monitoraggio delle tendenze è cruciale, poiché un server che si avvicina ripetutamente ai suoi limiti può rimanere online mentre l'esperienza dell'utente deteriora gradualmente.

Gli avvisi di soglia consentono agli amministratori di indagare sui precursori di un incidente prima che gli utenti perdano l'accesso.

7. Pianificare picchi di capacità e failover

Un'applicazione che sopravvive a guasti a livello hardware ma è completamente incapace di funzionare sotto richieste aumentate non è realmente resiliente a guasti di alcun tipo.

La pianificazione della capacità deve tenere conto non solo dei modelli di utilizzo quotidiano, ma anche dei picchi dovuti a richieste stagionali, cambi di turno, crescita o requisiti di hosting per altre applicazioni.

Particolarmente in ambienti di hosting multi-server, la perdita di un singolo server deve essere compensata assicurando che altri nodi di hosting abbiano capacità di riserva per accogliere eventuali processi che altrimenti verrebbero eseguiti sul nodo guasto.

Altrimenti, le procedure di fail-over potrebbero semplicemente trasformare un incidente isolato in un ampio problema di prestazioni del sistema.

8. Proteggi dati e configurazione

Un server Windows di sostituzione è di poco uso se l'IT non può ripristinare i componenti necessari per far funzionare l'applicazione.

Questo potrebbe significare che le procedure di backup devono includere dati delle applicazioni, database, file di configurazione, certificati, impostazioni delle applicazioni, profili utente, configurazione dell'infrastruttura, script e informazioni sulle licenze.

La strategia varierà a seconda dell'Obiettivo di Tempo di Ripristino (RTO) e dell'Obiettivo di Punto di Ripristino (RPO) dell'applicazione.

Soprattutto, assicurati che un backup riuscito non equivalga a un recupero riuscito. I team IT dovrebbero testare che sia possibile ripristinare l'intero servizio applicativo dai dati protetti e dalla configurazione.

9. Ridurre il raggio d'azione delle modifiche

Non sempre si tratta di un disastro imprevisto che causa interruzioni. Possono anche essere causate da miglioramenti implementati. Pertanto, le patch di Windows, gli aggiornamenti delle applicazioni e dei driver, le modifiche alle politiche di sicurezza e alla configurazione possono avere un impatto negativo sulla disponibilità dell'applicazione. Si consiglia di evitare di apportare modifiche simili a tutti gli host di produzione contemporaneamente, se possibile.

In un'installazione multi-server, è possibile eseguire le modifiche di miglioramento in fasi, consentendo così all'amministratore di assicurarsi che tutto funzioni correttamente. È anche essenziale avere la possibilità di annullare le modifiche apportate.

Pertanto, quando si progettano procedure di emergenza, dovrebbero essere considerate anche le opzioni di ripristino. Il processo dovrebbe essere adeguatamente documentato e il personale dovrebbe sapere cosa fare se un cambiamento fallisce, invece di lasciare semplicemente a loro discrezione.

10. Progettazione per una degradazione elegante

La resilienza non riguarda il mantenere il 100% delle funzioni normali attive e funzionanti in ogni momento.

In alcuni casi, sostenere le operazioni per utenti o applicazioni chiave può essere più importante che mantenere tutti i servizi disponibili per tutti gli utenti. Le priorità possono essere stabilite prima che si verifichi un incidente dai team IT.

Se c'è capacità disponibile che può essere utilizzata, potrebbe avere senso allocarla prima alla produzione, al servizio clienti, alla finanza o ad altre funzioni.

Questa è una degradazione elegante: mantenere la capacità di eseguire le funzioni che generano il maggior valore per l'azienda, invece di lasciare che il fallimento di elementi meno critici faccia crollare l'intero sistema.

Come dovrebbero i team IT monitorare la resilienza delle applicazioni?

Il monitoraggio dei singoli server può essere utile, ma il monitoraggio della resilienza dovrebbe riflettere il servizio totale dell'applicazione così come percepito dagli utenti.

Un modello realistico comprende diversi strati:

Strato	Cosa monitorare	Esempio di errore
Host	CPU, RAM, disco, disponibilità del sistema operativo	Server sovraccarico o offline
Applicazione	Stato del processo e del servizio	Crash dell'applicazione
Dipendenza	Database, DNS, identità, archiviazione	L'applicazione si avvia ma non può operare
Accesso	Gateway, portale, percorso di rete	Gli utenti non possono connettersi
Sessione	Utenti attivi, guasti, latenza	L'applicazione è online ma inutilizzabile
Funzione aziendale	Completamento del flusso di lavoro riuscito	L'utente non può completare il compito richiesto.

Il livello della funzione aziendale è uno dei più semplici da trascurare.

I cruscotti dell'infrastruttura possono mostrare tutti i server, i servizi e i percorsi di rete come sani, mentre il flusso di lavoro di un utente reale è compromesso. È quindi importante che le applicazioni critiche monitorino la loro salute dalla prospettiva dell'operazione che sono progettate per supportare.

Come dovrebbe essere testata la resilienza delle applicazioni?

Un'architettura di resilienza che non ha mai subito un guasto controllato contiene assunzioni non testate.

Utilizzare i test per valutare la risposta del sistema quando componenti chiave diventano non disponibili. I test dovrebbero includere la disconnessione di un host applicativo, l'interruzione di un servizio applicativo, la simulazione della perdita di un percorso di rete, la verifica del comportamento del gateway o del bilanciamento del carico, il ripristino da un backup e l'accesso all'applicazione da un endpoint alternativo.

I processi di test dovrebbero estendersi oltre gli aspetti tecnici del recupero. I team IT dovrebbero verificare se gli avvisi vengono inviati al personale amministrativo corretto, se i passaggi di recupero vengono eseguiti nella sequenza corretta e se gli utenti sono in grado di svolgere un'attività aziendale reale dopo che i servizi sono stati ripristinati.

Le procedure operative sono parte integrante di un sistema resiliente. Procedure di escalation degli avvisi: chi riceve l'avviso? Chi ha l'autorità di avviare il failover? Dove sono memorizzati la documentazione di recupero e le credenziali? Quale dipendenza deve essere attivata per prima?

La ridondanza tecnica offre pochi vantaggi se i processi per riacquistare l'accesso non sono stati testati.

Qual è la checklist per la resilienza delle applicazioni?

Prima di intraprendere un'applicazione Windows critica resiliente, i team IT dovrebbero essere in grado di rispondere alle seguenti domande:

• Quali processi aziendali si basano sull'applicazione?
• Quali sono i suoi RTO e RPO?
• Quali server, database e servizi esterni richiede?
• Dove si trovano i suoi punti critici di guasto?
• Un altro host dell'applicazione può accettare utenti se un host fallisce?
• Gli utenti possono connettersi se il loro endpoint o la loro posizione normale non è disponibile?
• C'è abbastanza capacità di riserva per un funzionamento degradato?
• Sono attivamente monitorati i problemi di infrastruttura, dipendenza e sessione?
• Gli amministratori vengono avvisati prima che le soglie importanti diventino interruzioni?
• I dati e la configurazione dell'applicazione sono protetti?
• È stata effettivamente testata la ripristino?
• È possibile annullare modifiche problematiche?
• È documentata la sequenza di recupero?
• Gli utenti possono completare il processo aziendale richiesto dopo il recupero?

Non tutte le risposte richiedono un'infrastruttura costosa ad alta disponibilità. Il giusto livello di protezione dipende dal costo e dall'impatto operativo dei tempi di inattività.

Ciò che conta è che le decisioni relative a disponibilità, ridondanza e recupero siano prese deliberatamente, piuttosto che presupposte.

Come può TSplus aiutare a mantenere disponibili le applicazioni Windows?

Per le organizzazioni che si affidano a applicazioni Windows esistenti, possiamo aiutare a migliorare la disponibilità centralizzando le applicazioni su server Windows gestiti e fornendole agli utenti tramite client compatibili con RDP, accesso in stile RemoteApp o un portale web HTML5. Questo riduce la dipendenza dai singoli endpoint degli utenti e offre ai team IT maggiore flessibilità quando gli utenti devono connettersi da un altro dispositivo o luogo.

TSplus Remote Access può anche supportare distribuzioni multi-server con bilanciamento del carico e accesso basato su gateway. Quando combinata con database resilienti, archiviazione, servizi di identità e networking, questa architettura può ridurre la dipendenza da un singolo host applicativo e aiutare a mantenere l'accesso alle applicazioni Windows critiche durante le interruzioni dell'infrastruttura.

Conclusione

La resilienza dell'applicazione dipende dalla comprensione del percorso completo tra infrastruttura e utilizzo aziendale. La ridondanza, il monitoraggio, il backup, la pianificazione della capacità e le procedure di recupero sono più efficaci quando sono progettate attorno a dipendenze dell'applicazione e obiettivi di recupero chiaramente definiti.

Per le applicazioni Windows esistenti, la resilienza spesso deriva dal rafforzare l'ambiente attorno al software piuttosto che ricostruire l'applicazione stessa. Il test chiave rimane semplice: quando si verifica un'interruzione, gli utenti possono continuare a lavorare o l'IT può ripristinare la funzione aziendale richiesta entro la finestra di recupero concordata?