Linuxはもうしばらく前から存在しています。 1991年にLinusTorvaldsによって最初に作成されましたが、Windowsや主要なUnixディストリビューションとともに、サーバーオペレーティングシステム（OS）ランドスケープの主要なプレーヤーに成長しました。 Unixには本質的に問題はありませんが、かなり「歯が長く」なっており、UnixからLinuxに移行する傾向が高まっています。
では、なぜ移行するのですか？
既存のデータセンター（オンプレミスまたはコロケーション施設）の管理者である場合、特に長い間存在している場合は、Unixの商用フレーバーを実行している可能性があります。これらは通常、独自のハードウェアを必要とし、これは問題なく実行されている可能性がありますが、そのようなレガシー環境を維持することには課題があります。上級管理職が検討している可能性のあるこれらの課題の最大のものは、ハードウェアとOS自体の両方のサポートコストです。さらに、レガシーハードウェアは古く、部品を見つけるのが難しく、見つかった場合は高価になる可能性があるため、拡張はますます困難になる可能性があります（ああ、需要と供給、あなたはとても厳しい愛人です！）。
この移行中に発生する可能性があるのは、移行できないアプリケーションを発見する可能性です。ベンダーが廃業したか、アプリケーションをLinuxに移植していない可能性があります。おそらく彼らは持っていますが、それは高すぎるコストを伴う専門的な関与への直接のベンダーの関与を必要とするでしょう。これが発生した場合は、ワークロードをLinuxでサポートされている新しいアプリケーションに移行できるかどうかを確認するか、その特定のレガシーサーバーを維持する必要があるかどうかを確認する必要があります。
レガシーUnixシステムを維持する上でのもう1つの問題は、仮想化できないことです。いくつかのUnix環境には仮想化がいくつかありますが、選択したハイパーバイザーでサポートされているOSに移行できる場合、最新のハイパーバイザーはより多くの機能と柔軟性を提供します。
さて、移行します。どうすれば開始できますか？
UnixからLinuxへの移行の成功は、しっかりとした調査から始まります。焦点を当てるべきことがいくつかあります。これにアプローチする方法は2つあり、両方のハイブリッドが最良の結果をもたらすことがわかりました。私が見たように、2つのアプローチは「ボトムアップ」と「トップダウン」です。これらのフレーズは一般的で、ここで適用するのは非常に簡単です。
ボトムアップアプローチでは、OSレベルから始めます。現在のOSとバージョンを確認することから始めます。インストールされているパッケージ、モジュール、またはOSベンダーからの追加ソフトウェアを特定します。次に、サードパーティのソフトウェアを確認し、実行しているベンダーとバージョンをキャプチャします。最後に、Cのような形式言語で書かれたプログラムだけでなく、自家製のソフトウェアもあります。 （またはその子孫のいずれか）またはJava 、一般的なシェル言語（sh）で記述されたスクリプトもあります 、ksh 、csh ）またはPERLのようなインタプリタ言語 、Python 、など。
もう1つの場所は、cronです。 スケジューラー。ベンダー提供であろうと自家製であろうと、そこでスケジュールされているものはすべて、テストに余分な時間を費やしたいものです。
トップダウンアプローチは、エンドユーザーから始めて、システム上で何を実行しているかをエンドユーザーから見つける必要があるため、より困難になる可能性があります。ユーザーは何かがどのように機能するかを常に理解しているわけではなく、それをどのように使用するかを理解しているとは限らないため、このアプローチは試してみることができます。たとえば、ユーザーは自分がWebサイトを使用していることを知っていても、「内部」がApacheであることを認識していない場合があります。 またはTomcat 、CGIがあるかどうか スクリプトとその言語。ただし、多かれ少なかれスタンドアロンであると考えていたサーバーが別のサーバーと密接に関連していることや、両方を次の場所に移行する必要があることを確認するなど、余分な情報を収集できます。同時に。
私の好みは両方を行うことです...私は特定のシステムのビジネスユーザーをリードしている人を見つけ、彼らがそれを何のために使用しているかを見つけるために彼らと会うことを試みます。また、それらが使用する機能を識別可能なシステムコンポーネントと一致させようとします。 1つの例はWebサーバーです。静的サーバーですか、それとも動的サーバーですか？サーバーにインストールされているパッケージを確認しても、それがわからない場合があります。それでも、ユーザーインタビューでは、サイトがWordPressに基づいていることがわかる場合があります 、つまり、同じサーバー上にあるか、同時に移行する必要がある可能性のある別のサーバー上にあるかにかかわらず、それを駆動するデータベースを見つける必要があります。
さて、これで何が実行されているのか、次に何が実行されているのかがわかりました。
移動するLinuxディストリビューションを決定する必要があります。この決定には多くの要素が含まれますが、率直に言って、それ自体がブログ投稿である必要があります。今のところ、私が強調するのは、サーバーで機能している機能を調べて、それらの同じ機能をサポートしているディストリビューションを見つける必要があるということです。たとえば、サーバーが単純なWebサーバーまたはFTPサーバーの場合、ほぼすべてのLinuxで十分です。サードパーティのソフトウェアを実行している場合、ベンダーは特定のディストリビューションのみをサポートしている可能性があるため、そのソフトウェアから始めて、そこから絞り込んでください。
ディストリビューションを選択したら、開発環境を構築し、ベースOSと必要なパッケージ、サードパーティソフトウェアなどをインストールします。テスト用にユーザーを設定し、プログラムとスクリプトをコピーするか、ユーザーがテストできることを確認します。
すべてが実行されますよね？
完璧な世界では、それは本当でしょう。しかし、私たちは皆、世界が完璧ではないことを知っています。 OSが提供する機能は、通常、そのままの状態で期待どおりに機能します。 Apacheのようなバージョンにジャンプする場合は、Webサイトを同じように実行するように構成する方法に違いがある可能性があります。ドキュメントは通常、そこにたどり着くのに役立ちます。サードパーティのソフトウェアには、さらに多くの問題が発生する場合があります。これらに対処する必要がある場合は、OSのバージョンレベルを確認してください。私が扱ったベンダーの1つは、RHEL 6をサポートしていますが、RHEL7はサポートしていません。 64ビットバージョンのOSをインストールした場合にも問題が発生する可能性がありますが、サードパーティベンダーは32ビットインストールでのみテストしました。
自家製のソフトウェアとスクリプトは別の問題です。誰がコードを書いたか、そしてそれがどれほど複雑かにもよりますが、そこで問題が発生することはほぼ確実です。 Linux OSにコンパイルをサポートする適切なライブラリがある限り、形式言語はより簡単に転送できます。
古いフレーバーのUnixで実行している場合は、言語が変更されている可能性があるため、問題が発生する可能性があります。特定のデフォルトが変更されている可能性があり、関数呼び出し、特にシステムコールのオプションが異なる可能性があります。推奨されるのは、オンにできるデバッグの量が最も多いコードの最初のコンパイルを実行し、問題を解決したら、デバッグをオフにして再コンパイルし、サーバーの負荷を節約することです。
>
スクリプトの場合も同じことが言えますが、奇妙な変更が行われる可能性が高くなります。個人的な経験から、標準のシェル（別名sh）が示されています ）スクリプトは通常、Bourne Again Shell（別名bash）で実行されます ）。それでも、実際にはエラーをスローしないが、期待される結果を生成しない隠れた落とし穴がある可能性があります。重要な例の1つは、HPUXの時代によく使用したこのコードスニペットです。
cat datafile.txt | while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”
HPUXでは、これは正常に機能しました。 RHELのbashでは、変数$saved_value そのシェルがスコープを実行していた方法とHPUXが実行した方法が原因で、空白になります。上記を次のように変更する必要がありました：
while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value” したがって、古いシステムと新しいシステムを並べて実行し、スクリプトへの同じ入力が両方のシステムで同じ出力を作成することを確認することが重要です。
さて、私たちはすべてのものをテストしました、今何ですか？
古いシステムから新しいシステムへのカットオーバーを実行する実際の手順は、環境によって複雑さが大幅に異なる可能性があります。トピックが実際に正しく処理されるためには、独自のブログが必要です。移行が完了したら、特に追加の移行を行う場合は、事後分析が便利です。何がうまくいき、何がうまくいかなかったかをしっかりと確認することで、次の移行プロジェクトに適用するための有用な「教訓」を生み出すことができます。
まとめ
この記事が、探すべきものの種類、行うべき会話、確立する計画を強調し、UnixからLinuxへの移行への旅の最初の一歩となることを願っています。うまくいけば、この記事から取り上げたものと少しの運があれば、比較的スムーズな移行が可能になります。
[Red Hat Enterprise Linuxを試してみませんか？今すぐ無料でダウンロードしてください。 ]