2013.07.07基礎的なことなんだろうなと思われるんだけども、SVMによるOSミラー構築手順なんかを押さえてみる。今回やろうとしているのは、上図にあるとおりOSディスクのミラーリング。V125にはディスクが2本搭載されており、いずれも容量は72GBとなっている。この中の左側のディスクにSolaris10をインストールしたばかりの状態になっているということで。普通、IAサーバを構築する際はハードウェアRAIDを使うことが多いのだけど、何故かSolarisはこのソフトウェアRAIDを使用するケースが非常に多い。ハードウェアRAIDを使用するケースを聞いたことがない。いうことで、恐らく押さえておかないと後々きついよなーと感じたので記事に起こしたしだいです。Solaris10を導入したディスクのパーティションテーブルを確認しておく。quitミラーリングするディスクのパーティションテーブルも確認しておく。quit当然だけど、パーティションテーブルの構造は全然違う。そもそも今回の場合、中古の機種を購入していた為、元々使われていたパーティションテーブルがそのままのっていたものと考えられるのだけど、次のコマンドで全てc1t0d0→c1t1d0に対してパーティションテーブルの同期を行う。143349311bash-3.2#以下のようになる。143176319bash-3.2#SVMはその構成データをメタDBという形で管理する。今回の場合、パーティション番号4番に対して作成していたスライスに対してこれを構成する。各ディスクごとにmetadbコマンドを使用して、2つずつのメタDBを作成した。メタDBの数は、ディスク搭載本数によって推奨値が決められていたように記憶してるけど、ちょっと見つけられていない。/dev/dsk/c1t1d0s4bash-3.2#現在使用中のディスクも含め、どんどんディスクをSVM管轄に含めていきます。この時点ではまだ2本のディスクをミラー化してはいません。各メタボリュームは正ディスクしかアサインしていません。setupbash-3.2#メタボリュームと各物理パーティションがSVM管轄になったかどうかを確認。id1,sd@SFUJITSU_MAW3073NCSUN72G_000747B0PAB1____DAN0P7B0PAB1起動ボリュームを、それまでの物理パーティションから、メタボリュームへ変更するコマンドを撃つ。/etc/vfstabファイルを参照すると、ルートパーティション設定が変更されていることを確認。–これに引き続き、メタ化したボリュームへのマウント設定変更を/etc/vfstabに対して仕掛けていく。古い設定はとりあえず消さずにコメントアウトしている。–bash-3.2#再起動してみて、起動できるかどうかを確認してみる。シリアルコンソールと言うのは非常に便利。実は、実際にこの再起動を行ったときは、メタボリュームを1つ構成し忘れており、それに伴うエラーメッセージが出力されていました。一応乗せておきますー。2005#無事にログインできたら、メタボリュームで正常にマウントして動いているかを確認しておく。/export/home#いいんぢゃないでしょうか。それでは、メタボリュームに対してミラーディスクの適用を行う。attachedbash-3.2#それぞれのボリューム状態を確認する。ミラーリングが開始されたばっかりである為、ステータスは全て「Resyncing」となっており、そのプログレス値が表示されている。これらが100%になったら、とりあえず構成としては出来上がりとなる。id1,sd@SFUJITSU_MAW3073NCSUN72G_000747B0PAB1____DAN0P7B0PAB1bash-3.2#一々metastatを実行してみて回るのもしんどいので、以下のようなコマンドを使うと便利っぽいです。done全てのミラーリングが完了すると、Resyncのプログレス値は表示されなくなる為、そこが判断基準になると思います。HDDでミラーリングを行ったところ、22:28に開始した同期処理は、およそ翌12:45ごろには完了していました。言うか、ルートパーティションの同期に時間がかかったっぽいです。最後に、ミラーの状態を確認します。id1,sd@SFUJITSU_MAW3073NCSUN72G_000747B0PAB1____DAN0P7B0PAB1bash-3.2#全てのボリュームのステータスが「Okay」であれば大丈夫と思います。VSAを作り上げ、そこでキャッキャウフフしてみることにする。やりたいことは以下の2つ。今回新設したVSAは上図の右側になる。キャッシュ検査がなされないようで、「高速化」という意味合いでいうと、少し微妙な感じです。言え、とりあえずCDNを通じてアクセスできるようにはなりましたので、載せてみることにしました。UTM9の追加を行った際に色々不具合が出てきました。Kubernetesに手を出した今度はk3sでございます。以前、kubeadmを使用してKubernetesを作っておりましたが、いろいろありまして結局のところスタンドアロン構成に戻してみたりした時期がありました。経路フィルタを掛けるIHANetに入って、ピアを3つほど現在張ってる状態になっているんですが、3つ目のピアリングを行った際、以下のような指摘をいただきまして。「ピアが上がったみたいです。3560にてipv6を実装した。StoreOnce-CatalystタイトルとURLをコピーしました。