1
2021年 01月 26日
openSUSE Tumbleweed を試してみた。Leap とどう違う？
ー似て非なる openSUSE、Leap と Tunbleweed
openSUSE Tunmleweed をインストールしてみたので、openSUSE とは何だ？ から openSUSE Leap と Tunbleweed の違いに付いて考えてみました。
まず、openSUSE Tumbleweed を KVM 環境にインストールしてみました。 20210115 Build です。６分ちょっとの動画です。音出ます。
openSUSE Tumbleweed 20210115 Install インストール
ー openSUSE Leap
Leap は「跳躍」の意味です。openSUSE のウェブページでは
Portal:15.2"また openSUSE Leap 15.2 では、 SUSE Linux Enterprise (SLE) 15 Service Pack (SP) 2 をベースとして構築された、多数のコミュニティパッケージが提供されています。このような共有型の構造は Leap 42.1 (SLE 12 SP1 ベース) から行なわれているものです。"
と紹介されています。基本的に有償版 SUSE Enterprise から構築された、SUSE のディストリビューションの一つです。私は無意識に "openSUSE" と言った場合は、Leap を示しています。
ーopenSUSE Tumbleweed
Tumbleweed は「転がり草」の意味です。良くハリウッドの「荒野のヒチニン」のような西部劇なんかで荒地を転がる草や枝の塊のアレの意味です。
Welcome to the Tumbleweed Portal"Tumbleweed ディストリビューションとは、純粋な openSUSE の ローリングリリース版 で、特定のリリース間隔によらずに最新の安定版を提供する仕組みです。このプロジェクトは、ユーザに対して最新のソフトウエアを安定して届けるための活動を行なっています。Tumbleweed は Factory と呼ばれる、 openSUSE のメイン開発コードベースを利用して作られています。 Tumbleweed は Factory 内にある最新のソフトウエアが統合され、安定化されてテストが完了した時点で更新されます。そのため、 Tumbleweed には最新の安定版ソフトウエアが日々配信され続けることになります。"
Tumbleweed の名前の通り、openSUSE Tumbleweed は「転がり草」のようなローリングリリースのバージョンで、同じ openSUSE とは言っても、Leap とは全く生まれも育ちも違うものだと考えて良いでしょう。実際にポータルに書かれてある様に、カーネルやドライバによっては「今日動いたものは明日も動く可能性がない」とあり、プロプラエタリなデバイスドライバが動かないケースはかなりあるようです。
SLE をベースとした openSUSE Leap と違い、openSUSE Tumbleweed は Factory 版をベースとしています。
Portal:Factory"Factory 内のパッケージは常に流動的で、バージョンや機能の固定化は行なわれません。それはつまり、 Factory 内にあるリポジトリは、安定していない場合があることを意味します。ディストリビューションの中枢をなすシステムパッケージに対しては、 openQA による自動テストが実施されます。この自動テストが正常に終了し、各種パッケージの構築処理が落ち着くと、リポジトリはダウンロードミラーに対して同期化を行なます。これはおおよそ、1週間あたり1回程度発生します。"
実際、openSUSE Tumbleweed を使った感想から、Leap と違って YaST の機能が制限されていたり（デフォルトで一部機能がインストールされていない）などの違いがあり、「基本の SUSE」らしさを感じる、悪く言うと「出来上がっていない荒っぽい」ディストリビューションであるという印象を受けました。openSUSE Tumbleweed は引き続き SUSE Linux Enterprise(SLE) の開発に引き継がれ、そこからオープン化されたものが openSUSE Leap になります。
SUSE Linux Enterprise の Basic インストールのような感じでしょうか、ここからシステムを YaST で使えるように仕立ててビルドするのは、かなり面倒くさい、と感じました。インストーラ自体の印象、流れは Leap とは変わりませんが、Linux のディストリビューションってインストーラが決めるものだと感じさせられるものです。カーネルも、アプリケーションも、全部元を正せば同じルーツなんですね。ディストリビューションはインストーラが色を付ける訳です。インストーラの機能は Linux ディストリビューションにとっては「顔と一緒」で、初めてディストリビューションに触れるヒトにとっては、とてもインパクトが大きなものなのです。その点では openSUSE Leap と Tiubleweed に大きな印象差はありませんが、内部の動きやパッケージ全体の構成はかなり違ったものになるでしょう。
SUSE Linux Enterprise のインストールはこちら
SUSE Linux Enterprise 15 (SLES15) のインストール
--
今回、はじめは openSUSE Leap 15.2 上の KVM 上で Tumbleweed をインストールしてみたのですが、何故か挙動不審で、 SLES15 の上で動かすとうまく一発インストールできました。要注意です。やっぱり SUSE を業務用で選ぶなら、徹底的にテストされた SUSE Linux Enterprise だなと思ったシーンです。
openSUSE を「使ってみたい」と「試してみたい」の間には微妙な温度差があります。openSUSE を「使ってみたい」場合は Leap を断然お勧めします。
openSUSE を「試してみたい」のであれば、Tumbleweed を選ぶことです。 Linux ユーザには様々なタイプがあり、実用的で安定性を求めるなら、やっぱり SUSE Linux Enterprise、手軽に安く安定している Leap、常に最新のパッケージにチャレンジするなら Tumbleweed という選択肢があります。
また openSUSE Leap を入れて、最新のパッケージにチャレンジしたい場合は software.ope.suse.org から、最新の Tumbleweed 向けのパッケージを入れて「試してみる」のもいい方法でしょう。
▲
by islandcenter
| 2021-01-26 11:48
|
Comments(0)
2021年 01月 08日
openSUSE 15.3 (alpha) が公開
ー CentOS に何がおこった？
CentOS Linux is dead—and Red Hat says Stream is “not a replacement”
CentOS8 は終わり CentOS Stream になると報じられ、CentOS Stream に危機感を感じている ユーザやデベロッパーも多いのでしょう。CentOS は RedHat から、「後出しジャンケン」で RHEL のソースコードから、ある意味「うまい汁」を吸って利用者を惹きつけてきたわけで、資金提供をはじめたレッドハットにすれば「CentOS は RedHat にとって一円の利益ももたらさない」と言われてしまうのも、まぁありえる話でしょうか。
CentOS8 が、「CentOS Stream」 として、Fedora に次ぐ RedHat のパイロットプロジェクトとして人身御供化されることになる決定に恐々としているユーザ、デベロッパーが多いわけですね。
ー SLE と密着する openSUSE Leap 15.3 alpha が登場
昨年末 openSUSE Leap15.3 のアルファリリースが公開されました。openSUSE は、本家 SUSE Enterprise Linux (SLE) の先導プロジェクトの様に言われる事が多いのですが、SUSE15 以降、openSUSE tumbleweed がパイロットプロジェクトに位置し、openSUSE Leap は SLE ベースの、言わば SLE の「後出しジャンケン」の位置になりました。
私は SLES からこの世界に入ったので、openSUSE はちょっと手を出し辛かったンですが、 SLE のコミュニティ版とも言える openSUSE Leap 15 からは、SLE と共通部分が多く、実に使いやすく安定したディストリビューションになりました。
安心して中小規模の軽サーバー運用にも耐えられます。
Alpha Releases of openSUSE Leap 15.3 are Available for Testing「openSUSE Leap 15.3 Alpha」が登場，CentOSユーザにもアピールへ
Portal:Leap
ー openSUSE Leap 15.3 (alpha) の何が変わる？
今回はインストールだけしたので、中身がどう変わったのかについては触れません。インストーラで一番目に付いたのは、デフォルトパーティションのプロポーザルです。中身の改良は大いに歓迎。だけど変わらない事を好む利用者もいるということです。
インストールデバイスの全てのパーティションを / (ルート) BtrFS で提案してきました。仮想化運用の低負荷サーバーならこれでもいいかも知れません。
今回は KVM を使うならという前提でインストールのストーリーを作ってみました。/var だけ別パーティションにしています。
実際のインストールは簡単に動画にまとめました。（盛大に音出ます）
openSUSE Leap 15.3 alpha Install & First Look インストール
ー インストール直後にもたつく動きがある
一点、気になったのは、インストール直後の最初のログインで、YaST の挙動と言うか、レスポンスに問題がありました。YaST のソフトウェア管理、リポジトリ管理のアプレットがなかなか起動しない。デバッグコードの為か、たぶんバックグラウンドで何かの最終処理をしているのでしょうか、たぶん。インストール後、最初の起動からもう一度再起動すると治りました。
ー ますます密着する openSUSE Leap と SLE
どうも、openSUSE Leap は SUSE Linux Enterprise (SLE) とのバイナリ互換と密接性を求めて行くようです。オープン・フリーな openSUSE Leap に SLE の堅牢さが加わる事で、言わば "SLE の CentOS" になろうとしているようです。
ただ、RHEL クローンだった CentOS ユーザが、系列の異なる openSUSE Leap に靡くかと言えば難しいでしょう。RHEL クローンは他に沢山あるし、 CentOS ユーザがそちらに大挙移行するケースがありそうです。いずれにせよ openSUSE Leap が他のディストリビューションと差別化された高い信頼性や使い勝手を身に着けた方向性に進む事を歓迎しています。
▲
by islandcenter
| 2021-01-08 14:42
|
Comments(0)
2021年 01月 08日
SUSE15(SLE15x/openSUSE Leap15x) で NTP タイムサーバー
SUSE15(SLE15x/openSUSE Leap15x) で NTP タイムサーバーを稼働させます。
知らなかったで済まされなかったンですが、いろいろ言い訳はありますよ。古い SLES11 を NTP サーバーとしていたので気にならなかったのですが、openSUSE Leap 15.2 に変えてからどうもNTPサーバーがおかしい。ってか全然機能していない。
よく見たらフレッシュにインストールした openSUSE Leap 15.2 って ntpd のサービスが YaST Service Manager にないんです！こりゃおかしいと思って調べてみました。
SUSE 15(SLE15/openSUSE15)では、ntpd ってなくなっていたんですね。その代わりに chrony というパッケージに置き換わっていました。
という事で、 SUSE Linux 15 (SLE15/openSUSE Leap 15) で NTP サーバー chronyd を動かしてみました。
31 Time Synchronization with NTPchronyc(1) Manual Page
ー chrony パッケージ
chrony パッケージは、デフォルトで SLE/openSUSE 15x のインストーラがインストールしてクライアントとして機能します。別途インストールする必要はないのですが、なければ 1 クリックインストールします。こちら
chrony System Clock Synchronization Client and Server
ー /etc/chrony.conf の書き換え
デフォルトでは chronyd はクライアントとして動作します。 YaST > Network Services > NTP Configuration で」タイムソースを指定すると、 /etc/chrony.conf ファイルは YaST により更新されます。
YaST で更新されない部分が allow の行です。ここはコメントアウトされているので、自身がタイムソースとなる場合、提供する相手の IP アドレスを次の様に指定します。
chrony.conf を書き換えたら、chronyd を YaST > System > Service Manager か systemctl コマンドで再起動します。
suse15:~ # cat /etc/chrony.conf | grep llow# Allow the system clock to be stepped in the first three updates# Allow NTP client access from local network.#allow 192.168.0.0/16allow 192.168.1.0/24suse15:~ # systemctl restart chronydsuse15:~ # systemctl status chronyd● chronyd.service - NTP client/server: 以下略
SUSE の場合、YaST > Network Services > NTP Configuration から、タイムソースを追加して、TEST ボタンを押すと、NTP ソースとして機能しているかをテストすることができます。
どうやら動いているようです。
ちなみにタイムソースを設定する場合、デフォルトで "Quick Initial Sync" にチェックがはいっており、iburst オプションが有効になります。
SLES 15 は SLES12 よりアップデートしたものなので、ntpd が残っていたのですが、YaST > Software Maanagement から削除してしまいました。
ー slew モードと step モード
chrony のデフォルトは step モードです。デフォルトで、タイムソースとの一秒以上の時刻ズレを３回以上検出すると、一挙に時刻合わせを行います。時刻のズレが大きいとアプリケーションによっては深刻な誤動作（時刻戻りによる）が発生する場合があるので、slew モード(徐々寄せモード)にするのが良いでしょう。ただし slew モードは時刻ズレが大きいと同期に時間がかかります。時刻ズレがあまり影響ない場合はデフォルトの Step モードでも構いません。
isLandcenter.jp
SLES 15 は SLES12 よりアップデートしたものなので、ntpd が残っていたのですが、YaST > Software Maanagement から削除してしまいました。
ー slew モードと step モード
chrony のデフォルトは step モードです。デフォルトで、タイムソースとの一秒以上の時刻ズレを３回以上検出すると、一挙に時刻合わせを行います。時刻のズレが大きいとアプリケーションによっては深刻な誤動作（時刻戻りによる）が発生する場合があるので、slew モード(徐々寄せモード)にするのが良いでしょう。ただし slew モードは時刻ズレが大きいと同期に時間がかかります。時刻ズレがあまり影響ない場合はデフォルトの Step モードでも構いません。
# makestep 1.0 3 # Comment Out
leapsecmode slew # <--- Add Line
デフォルトではポーリング間隔(Polling interval) minpoll 64sec / maxpoll 1024sec です。詳細はマニュアルでご確認ください。
chrony.conf(5) Manual Page
▲
by islandcenter
| 2021-01-08 12:38
| SUSE
|
Comments(0)
- zabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視する。snmp Agent, zabbix Agent の設定 -
ここでは、SUSE Linux Enterprise 15 (SLE15) と openSUSE Leap 15 を対象に zabbix 5.2 で監視する snmp と zabbix Agent の設定方法について説明しています。
ー snmpd の設定
YaST か zypper で net-snmp パッケージをインストールします。
# yast
Software > Software Management より "snmp" などでサーチして net-snmp をインストールrします。
/etc/snmp/snmpd.conf の rocommunity の行に、 Community string ここでは "public" とネットワークアドレスを設定します。
opensuse15:~ # cat /etc/snmp/snmpd.conf | grep community# to enable it uncomment the rwcommunity line and change the community# rocommunity public 127.0.0.1rocommunity public 192.168.1.0/24# rwcommunity mysecret 127.0.0.1opensuse15:~ #
# yast
System > Services Manager より、snmpd を Start, On boot enable にセットします。もしくは systemctl コマンドで有効化します。
systemctrl で行う場合
opensuse15:~ # systemctl start snmpdopensuse15:~ # systemctl enable snmpdopensuse15:~ # systemctl status snmpd● snmpd.service - Simple Network Management Protocol (SNMP) Daemon.Loaded: loaded (/usr/lib/systemd/system/snmpd.service; enabled; vendor preset: disabled)Active: active (running) since Sun 2021-01-03 16:54:32 JST; 2s agoMain PID: 7541 (snmpd)Tasks: 1CGroup: /system.slice/snmpd.service└─7541 /usr/sbin/snmpd -LS0-6d -fJan 03 16:54:34 opensuse15 snmpd[7541]: Connection from UDP: [192.168.1.221]:59884->[192.168.1.3]:161: 略opensuse15:~ #
zabbix サーバー側から snmpwalk で string が返ってくるか確認します。
zabbix:~ # snmpwalk -v 2c -c public opensuse15.mydomain.com .1.3.6.1.2.1.1SNMPv2-MIB::sysDescr.0 = STRING: Linux opensuse15 5.3.18-lp152.19-default #1 SMP Tue Jun 9 20:59:24 UTC 2020 (960cb00) x86_64SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (4960) 0:00:49.60:: 略:
ー Community String の変更
WAN 越しにクラウドサービスを監視したい場合や大規模ネットワークの場合、 Community String をデフォルトから変更して運用するケースが多くあると思います。
その場合、Configuration > Hosts > "Your Hostname" > Macros > Inherited host macros を選んで
{$SNMP_COMMUNITY} > Change リンク > 「"public" を別なストリングに変更」します。
ー zabbix agent のインストールと設定
次のページから、SUSE Linux Enterprise 15 用のリポジトリを登録するコマンドをコピーして実行します。
Download and install Zabbix
SUSE Linux Enterprise 15 用のコマンドは次の様に記述されています。
# rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpm# zypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'
リポジトリの登録ができたら zypper か YaST を使って zabbix agent をインストールします。
# yast
Software > Software Management で "zabbix" でサーチ、zabbix-agent をインストールします。
/etc/zabbix/zabbix_agentd.conf の Seerver= , ServerActive= の2行に送信先 zabbix Server のアドレスを記述します。
sles15:~ # cat /etc/zabbix/zabbix_agentd.conf | grep mydomain.comServer=zabbix.i.mydomain.comServerActive=zabbix.i.mydomain.comsles15:~ #
YaST か systemctl コマンドで zabbix agent を有効化します。
YaST > System > Services Manager で、 Zabbix Agent を Active/Onboot に設定します。
エラーがないか確認します。
sle15:~ # systemctl status zabbix-agent● zabbix-agent.service - Zabbix AgentLoaded: loaded (/usr/lib/systemd/system/zabbix-agent.service; enabled; vendor preset: di>Active: active (running) since Sun 2021-01-03 17:12:04 JST; 30s agoProcess: 12512 ExecStart=/usr/sbin/zabbix_agentd -c $CONFFILE (code=exited, status=0/SUCC>Main PID: 12514 (zabbix_agentd)Tasks: 6CGroup: /system.slice/zabbix-agent.service├─12514 /usr/sbin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf├─12515 /usr/sbin/zabbix_agentd: collector [idle 1 sec]├─12516 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]├─12517 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]├─12518 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]└─12519 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]Jan 03 17:12:04 opensuse15 systemd[1]: Starting Zabbix Agent...Jan 03 17:12:04 opensuse15 systemd[1]: Started Zabbix Agent.
後は、サーバー側の設定で zabbix Agent と snmp agent で監視します。
ー まとめ
zabbix と SUSE Linux (SLE/openSUSE Leap) で監視ターゲット側の設定をまとめました。
openSUSE Leap は 15 以降、SUSE Linux Enterprise との互換性が高くなり共通点も多く、デスクトップ用途以外のサーバ用途でも安定しています。I/F をはじめとするルック＆フィールも SLE と共通なので、ヘルプデスクやオペレータのトレーニングにも最適です。
openSUSE Leap は使いやすいディストリビューションになりました。中小規模環境でミッションクリティカルな用途以外で zabbix の様な用途で openSUSE Leap を使うのは一つの良い選択です。
ここにない内容は次の記事を参考にしてください。
Zabbix3 でSNMPデバイスを監視するHow to setup zabbix4.2 on openSUSE Leap 15.1 セットアップZabbix4.2 snmp監視 デバイスのグラフを表示させるまでzabbix4.2 を zabbix5.0 アップデート openSUSE Leap 15.1Zabbix 5.2 on openSUSE Leap 15.2
▲
by islandcenter
| 2021-01-04 13:44
| SUSE
|
Comments(0)
長い事 SUSE Linux をやっていると、 YaST GUI にあまりにも慣れすぎてしまって、すっかりキーボードをたたく事に億劫になってしまいます。Linux やってるエンジニアがキーボードにこだわるのはわかりますが、私は SUSE Linux 使う上ではマウスにこだわるヒトになってしまいました。
良くテレビドラマやニュースの資料映像なんかで、ブラインドタッチがやたらと早くて、マウスなんて全然つかってないじゃないか、という資料映像みたいなシーンを見ますが、私にはわかる。
「嘘だ、演技だ」
特に「ハケンの品格２」の篠原涼子のキーボード叩く演技は下手だったなぁ。ブラインドタッチになってない。ただ指がキーボードの上を撫ぜてるだけで「スーパー派遣」の品格がなかった。下手なビデオのオフィスシーンの方が演技している場合があるンですよ。
逆にマウスを使いこなしているシーンを見ると「演技っぽくなくリアル」に思えてくるものです。
それくらいいまの時代、マウスは重要です。
まぁ与太はそこまでにして
ー virt-manager GUI で KVM ゲストのライブマイグレーション
というのが今回のテーマです。
随分と昔に XEN 環境＋ iSCSI NAS を使ったライブマイグレーションをやた事を思い出します。
iSCSI 上に仮想イメージを導入し、ついでに Live Migration してみる
時は移り変わり、まず XEN は見なくなったし SUSE でも XEN から KVM への移行ガイドを用意するくらい、仮想化と言えばすっかり KVM の時代になってしまいました。
かわいそうな Citrix ....
今回は SUSE Linux Enterprise 15.0 と openSUSE Leap 15.2(gnome) 上で KVM が稼働しているので、それぞれライブマイグレーションしてみました。virsh migrate --live .... コマンドではなく、 virt-manager、 GUI を使います。
※ SLE 側は gnome Desktop のみです。openSUSE Leap 側も gnome Desktop を使っています。
ー リモート virt-manager に接続
openSUSE Leap 15.2 側の X 端末から Virtual Machine Manager GUI. を起動して、別なハイパーバイザー(SLES15 KVM)側に接続します。
# virt-manager &
openSUSE より File > Add Connection から、SLES の KVM ハイパーバイザーにログインします。そうするとエラー。
openssh-askpass パッケージが要求されます。
yast を見ると ssh-askpass は既にインストールされていますが、ssh-askpass-gnome はインストールされていないため、追加インストールします。
openSUSE Leap 16.2 では標準リポジトリに openssh-askpass, openssh-askpass-gnome が標準で含まれているため、zypper か YaST でインストールするだけです。
接続先のパスワードが要求されました。
リモートハイパーバイザーに接続できました。
稼働中のVMをポイントして右ボタンから Migrate をします。
今回はネットワーク上の共有ストレージ（iSCSI や NFS）を使っていない（単にイメージをSCP コピーしただけの手抜き）ので、エラーとなりました。Advanced Option の中に Allow unsafe のチェックボックスがあるのでこれをチェックして、強引にマイグレートしてみます。(敗因)
無事、SLE のインスタンスを openSUSE Leap 側に移行出来ました。
ー よくあるトラブル
よくあるトラブルとして、移行元、移行先のディレクトリ構造が違ったり、移行先に、仮想イメージがマウントしているインストールDVDメディアがないなどが原因で移行出来ないトラブルがあります。使わないハードウェアは外しておきます。VM のコールドブートが必要ですけど...
ー 頻繁に認証を求められる
リモートハイパーバイザーにアクセスすると、頻繁に root パスワードを求めてきました。原因／意味不明です。ちょっと実用的ではないですね。(敗因)
ー SLE の場合
SUSE Linux enterprise (SLES) 15 の場合、openssh-askpass, openssh-askpass-gnome は標準リポジトリに含まれないため、software.opensuse.org より１クリックインストールするか、expert Download にある指示に従って、リポジトリの追加、インストール
します。
openssh-askpass-gnome
openssh-askpass
zypper addrepo https://download.opensuse.org/repositories/openSUSE:Leap:15.2:Update/standard/openSUSE:Leap:15.2:Update.repozypper refreshzypper install openssh-askpass-gnome
zypper addrepo https://download.opensuse.org/repositories/openSUSE:Backports:SLE-15-SP3/standard/openSUSE:Backports:SLE-15-SP3.repozypper refreshzypper install openssh-askpass
zypper でインストールできない場合は YaST のソフトウェア管理 (YaST Software Management) でインストールできました。
opensuse152:~ # rpm -qa openssh*openssh-askpass-1.2.4.1-bp153.1.3.x86_64openssh-askpass-gnome-7.6p1-7.13.x86_64openssh-helpers-7.6p1-7.8.x86_64openssh-7.6p1-7.8.x86_64opensuse152:~ #
今度は openSUSE Leap に移動した、VM インスタンスを SLE 側に戻しました。
よくあるトラブル
ー 移行先のメモリが足りない
メモリアロケーションエラーになります。メインで使っているハイパーバイザーの稼働率が高く、８割程度でパツンパツンのところに、無理してマイグレートしないことです。不要不急のVMインスタンスをシャットダウンして、移行させるとうまく移行できます。
そもそもライブマイグレートは負荷の高い、ミッションクリティカルなサービスを移動させるのが本質的な目標なので、インスタンスを止めるのは本末転倒かもです。
ー 必ずネットワークの共有ディスクを使うこと、バックアップは重要
今回は手抜きして、 QEMU のイメージと XML ファイルを SCP コピーして、マイグレートしましたが、できたできたと喜んでマイグレートしてたら、遂にブートローダーが壊れて起動できなくなりました。まぁ今回はテスト環境で、スレーブ用DNSサーバーだったので笑って済ませますが、本番環境がこの様な事では済まされません。
必ずバックアップを取って、共有ディスクからマイグレートします。
ー 異なる環境ではマイグレートできない
インスタンスのイメージがあるディレクトリなど環境は必ず揃えること。特に、インスタンスを作ったときのインストールDVDメディアは、仮想ハードウェアから削除しておくことです。
ー ２つのハードウェアの違いはあるか
ライブマイグレーションの大きな課題としては、双方のハードウェアアキテクチャに大きな違いがあってはいけないことです。一度 XEN 時代にテストしたのですが、AMD アキテクチャから Intel マシンの移行は、コールド移行もできませんでした。同じ Intel 系でも、CPU世代が大きく違ったりする場合のライブマイグレーションがどの程度成功するかは未知数です。どれだけ環境が異なると移行できないかは経験を積むしかないでしょう。
また移行先のハイパバイザーが古かったりOSベンダーが異なると、成功の可能性は低そうです。
例えば、最新の XEON プロセッサ搭載サーバーから、数年前の古い Core i3 の古いデスクトップ応用PCへの移行がうまく行くとは思えません。コールドマイグレーションでさえ失敗しそうです。逆のケースではうまくいきそうなきがします。（ ...そう思っているだけですが… ）
いずれにせよ、いざと言う時にライブマイグレーションがおこなえるかどうか、システムを止められる機会に、計画的にテストしておく事が重要です。
ー まとめ
ライブマイグレーションは万能の機能ではありません。想定していなかった設定ミスで失敗したり、
起動できなくなるというトラブルもありました。個人的にはサービス停止が、１０分許されるなら、イメージの別 HV へのコピー、サービス 再起動でいい。仮想化マイグレーションは、運用技術としては自己満足に陥りやすい危険性があります。
ただし、せっかくハイパーバイザー運用するつもりなら、キチンと iSCSI などの共有ストレージを作って２つ以上の HV 運用を検討すべきでしょう。いざという時に提供される手段だし、緊急時のオペレーションテスト、訓練も重要です。
また、「小＞大」、「古＞新」のマイグレーションは成功の可能性が高いのでしょうが、新しいサーバーから古いハイパーバイザーハードウェアへの移行はかなり不安があります。いずれにせよ行き当たりばったりのチャレンジは避けた方がよさそうです。
今回は、SUSE Linux15(SLE/openSUSE Leap) で GUI からライブマイグレーションをテストしてみました。実用性、可用性はギリギリ合格点。 実運用には Open stack などを検討すべきでしょう。
また、SLE ではなく openSUSE Leap 15.2 をつかってみた初めての KVM ですが、使用感は SLES とそれほど変わらないので、ミッションクリティカルではないシーンでは openSUSE Leap でも充分かなと感じました。
▲
by islandcenter
| 2021-01-01 20:56
| SUSE
|
Comments(0)
1
