Linux è in circolazione da un po' di tempo ormai. Creato inizialmente da Linus Torvalds nel 1991, è diventato uno dei principali attori nel panorama dei sistemi operativi server (OS), insieme a Windows e alle principali distribuzioni Unix. Sebbene non ci sia nulla di intrinsecamente sbagliato in Unix, è diventato piuttosto "lungo nel dente" e c'è una tendenza crescente a migrare da Unix a Linux.
Allora perché migrare?
Se sei un amministratore di un data center esistente (sia in sede che in una struttura di co-location), in particolare uno che esiste da molto tempo, è probabile che tu abbia un sapore commerciale di Unix in esecuzione. Questi di solito richiedono hardware proprietario e, sebbene possa funzionare senza problemi, ci sono delle difficoltà nel mantenere tali ambienti legacy. La più grande di queste sfide che il management superiore potrebbe dover affrontare sono i costi di supporto sia per l'hardware che per il sistema operativo stesso. Inoltre, le espansioni possono essere sempre più difficili da fare, poiché l'hardware legacy è obsoleto e le parti possono essere difficili da trovare e, una volta trovate, possono essere costose (oh, domanda e offerta, sei un'amante così dura!).
Qualcosa che può emergere durante questa transizione è la possibilità di scoprire un'applicazione che non può essere migrata. Forse il fornitore ha cessato l'attività o non ha portato l'applicazione su Linux. Forse sì, ma richiederebbe il coinvolgimento diretto del fornitore in un impegno professionale che comporta un costo troppo elevato. In tal caso, potresti dover vedere se puoi migrare il carico di lavoro su una nuova applicazione supportata su Linux o cercare di mantenere quel particolare server legacy in giro.
Un altro problema relativo alla permanenza su sistemi Unix legacy è l'impossibilità di virtualizzare. Sebbene sia presente una certa virtualizzazione in alcuni ambienti Unix, i moderni hypervisor offrono molte più funzionalità e flessibilità, se puoi passare a un sistema operativo supportato dall'hypervisor scelto.
Ok, quindi eseguirò la migrazione, come inizio?
Il successo di una migrazione da Unix a Linux inizierà con una solida indagine. Ci sono diverse cose su cui concentrarsi. Ci sono due modi per avvicinarsi a questo, e ho scoperto che un ibrido di entrambi può produrre i migliori risultati. I due approcci, come li ho visti, sono "dal basso verso l'alto" e "dall'alto verso il basso". Queste frasi sono comuni e abbastanza facili da applicare qui.
Per l'approccio dal basso verso l'alto, inizi a livello di sistema operativo. Inizia controllando il sistema operativo e la versione correnti. Identifica i pacchetti installati, i moduli o il software aggiuntivo dal fornitore del sistema operativo. Quindi, controlla la presenza di software di terze parti, acquisendo il fornitore e la versione in esecuzione. L'ultima cosa è qualsiasi software autoprodotto che potresti avere, inclusi non solo programmi scritti in un linguaggio formale come C (o uno dei suoi discendenti) o Java , ma anche script scritti in uno qualsiasi dei comuni linguaggi di shell (sh , ksh , csh ) o linguaggi interpretati come PERL , Python e simili.
Un altro posto dove cercare è cron pianificatore. Tutto ciò che è programmato lì, sia che sia fornito dal fornitore o coltivato in casa, è qualcosa che vuoi dedicare più tempo ai test.
L'approccio dall'alto verso il basso può essere più difficile, poiché implica partire dagli utenti finali e scoprire da loro cosa eseguono sul sistema. Questo approccio può essere un'esperienza impegnativa, poiché gli utenti non sempre capiscono come funziona qualcosa, ma solo come la usano. Ad esempio, un utente potrebbe sapere di utilizzare un sito Web, ma non essere consapevole del fatto che "sotto il cofano" è Apache o Tomcat , indipendentemente dal fatto che abbia o meno un CGI script e, in caso affermativo, in quale lingua si trovano. Tuttavia, è possibile raccogliere informazioni extra, come scoprire che un server che ritenevi più o meno autonomo è strettamente legato a un altro e che dovrai migrarli entrambi su allo stesso tempo.
La mia preferenza è fare entrambe le cose... Cercherò di scoprire chi guida gli utenti aziendali di un particolare sistema e incontrarli per scoprire per cosa lo usano. Cercherò anche di abbinare le funzionalità che usano con componenti di sistema identificabili. Un esempio potrebbe essere un server web. È un server statico o dinamico? Potresti non vederlo dalla revisione dei pacchetti installati sul server. Tuttavia, un'intervista con un utente potrebbe dirti che il sito è basato su WordPress , il che significa che devi trovare il database che lo guida, sia che si trovi sullo stesso server o forse su un altro che potrebbe dover migrare contemporaneamente.
Ok, quindi ora so cosa è in esecuzione, e dopo?
Devi decidere a quale distribuzione Linux intendi passare. Molte cose influiscono in questa decisione, che francamente dovrebbe essere un post sul blog a sé stante. Per ora, ciò che evidenzierò è che è necessario esaminare le funzionalità in gioco sul server e scoprire quali distribuzioni supportano quelle stesse funzionalità. Se, ad esempio, il server è un semplice server Web o FTP, qualsiasi Linux sarà sufficiente. Se hai software di terze parti in esecuzione, il fornitore potrebbe supportare solo determinate distribuzioni, quindi potresti voler iniziare con quel software, quindi restringere il campo da lì.
Dopo aver selezionato la distribuzione, crea un ambiente di sviluppo, installa il sistema operativo di base e i pacchetti necessari, software di terze parti e simili. Configura gli utenti per il test e copia i loro programmi e script oppure assicurati che possano farlo.
Tutto funzionerà, giusto?
In un mondo perfetto, sarebbe vero. Tuttavia, sappiamo tutti che il mondo non è perfetto. Le funzionalità fornite dal sistema operativo generalmente funzionano immediatamente come ci si aspetterebbe. Se stai saltando nelle versioni per qualcosa come Apache, potrebbero esserci differenze nel modo in cui configurarlo per far funzionare il tuo sito web allo stesso modo. La documentazione di solito ti aiuta ad arrivarci. Il software di terze parti a volte può avere più problemi. Se devi affrontarli, assicurati di aver confermato i livelli di versione del sistema operativo. Un fornitore con cui ho avuto a che fare supporta RHEL 6, ma non RHEL 7. A volte potrebbero aver testato solo fino a un determinato punto di rilascio e supportare fino a quello ma non oltre, come il supporto di RHEL 6.4 ma non RHEL 6.10. Potrebbero esserci problemi anche se hai installato una versione a 64 bit del sistema operativo, ma il fornitore di terze parti ha testato solo su un'installazione a 32 bit.
Il software e gli script fatti in casa sono un'altra questione. Hai quasi la certezza di avere problemi lì, a seconda di chi ha scritto il codice e di quanto sia complesso. I linguaggi formali possono essere trasferiti più facilmente, purché il sistema operativo Linux abbia le librerie giuste per supportare la compilazione.
Potrebbero esserci problemi se stavi utilizzando una versione precedente di Unix, poiché le cose potrebbero essere cambiate nella lingua. Alcune impostazioni predefinite potrebbero essere cambiate e le opzioni per le chiamate di funzione, in particolare le chiamate di sistema, potrebbero essere diverse. Il consiglio è di eseguire le prime compilazioni del codice con la massima quantità di debug che puoi attivare e quindi, una volta che hai risolto i problemi, ricompilare con quel debug disattivato per risparmiare sul carico del server in futuro.
Per gli script, lo stesso vale, ma con una maggiore possibilità di modifiche dispari. L'esperienza personale ha dimostrato che la shell standard (aka sh ) gli script di solito vengono eseguiti sotto Bourne Again Shell (aka bash ). Tuttavia, possono esserci trucchi nascosti che in realtà non generano un errore, ma non producono i risultati attesi. Un esempio chiave è questo frammento di codice che ho usato molto nei miei giorni con HPUX:
cat datafile.txt | while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”
Sotto HPUX, questo ha funzionato bene. Sotto bash in RHEL, la variabile $saved_value sarebbe vuoto, a causa del modo in cui quella shell stava eseguendo l'ambito rispetto a come lo faceva HPUX. Ho dovuto cambiare quanto sopra in qualcosa del genere:
while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value” Pertanto, è importante eseguire esecuzioni affiancate tra il vecchio sistema e il nuovo per verificare che lo stesso input in uno script crei lo stesso output su entrambi i sistemi.
Ok, abbiamo testato tutte le cose, e adesso?
Il passaggio effettivo di eseguire il passaggio dal vecchio sistema al nuovo può variare notevolmente in termini di complessità, a seconda dell'ambiente. Affinché l'argomento sia davvero gestito correttamente, dovrebbe avere un proprio blog. Dopo aver eseguito la migrazione, un'autopsia è utile, soprattutto se hai altre migrazioni da fare. Una solida revisione di ciò che ha funzionato e di ciò che non è andato così bene può generare utili "lezioni apprese" da applicare al tuo prossimo progetto di migrazione.
Conclusione
Spero che questo articolo abbia aiutato a mettere in evidenza i tipi di cose da cercare, le conversazioni da avere, i piani da stabilire e ti abbia dato un vantaggio nel tuo viaggio verso le migrazioni da Unix a Linux. Si spera che, con le cose che porti via da questo articolo e un po' di fortuna, avrai una transizione relativamente fluida.
[ Vuoi provare Red Hat Enterprise Linux? Scaricalo ora gratuitamente. ]