vSphere 5.5 から 6.0にアップグレードした話
vSphere 5.5から6.0にアップグレードしたよ
環境は以下の通り
- ESXi 5.5 x3
- vCenter Server Virtual Appliance(vCSA) 5.5
アップグレード方法
5.5 to 6.0 はインプレースアップグレードができます。
- vCSAをアップグレードする
- ホストをアップグレードする
- 仮想マシンをアップグレードする
vCSAをアップグレードする
公式の手順スライドがあったので参考にしました。助かります。
まずは、vCSA 6.0のインストールメディアをダウンロード。 isoファイルなんだけど、5.5までとは違ってVMイメージが入っているわけではなく、 管理クライアント側でマウントする用です。
6.0用のクライアント統合インテグレーションプラグインをインストールして、 setup用のhtmlを叩くとインストールかアップグレードか聞かれます。
その後はウィザードに従って進めていけばOK。
5.5のvCSAはシャットダウンされた状態で残るので、必要ないなら消してしまいます。
Active Directory認証していたんですが、その設定が消えているのでadministrator@vsphere.localでログインして、 管理からADのアイデンティティ追加してユーザー権限設定すればOK。
ホストをアップグレードする
こちらはVMをローテーションしながらアップグレード。 ホストをメンテナンスモードにしてからESXi 6.0のイメージをマウント。 再起動してマウントしたイメージから起動し、ESXi 5.5のインストールされているデータストアを指定すると、 アップグレードの選択肢が出てくるのでそのままアップグレード。
仮想マシンをアップグレードする
ホストのアップグレードが終わったら、仮想マシンのVMware Tools、仮想ハードウェアのアップグレードします。
VMware Toolsは自動アップグレードが使えるので、VMware Toolsの期限切れ警告からポチーで完了ですね。 仮想ハードウェアの更新はしていません。
見たところ、バージョン10→11にするとCPU、メモリ、ビデオメモリ、PCIパススルー、シリアルポートが強化されるようですが、 今のところ足りているので、すぐにはアップグレードしないかなぁ。。。
vRealize Operations Managerを導入した話
vSphere 5.5から6.0にアップグレードをしたんですが、 ついでにvRealize Operations Manager(旧：vCOM)を導入しました。
導入する理由
vCenterでアラートメールを飛ばしたいんですけど、
vCenterはメール送信時の認証に対応していないという仕様があります。
私が使っているメールサーバーは認証必須なので、vCenterではメールアラートが飛ばせない。困る。
なんと、vCOMだとその辺も対応してるんですね。これはvCOM入れなければ！！！（vmware狙ってやってるでしょコレ）
導入方法
.ovaファイルが公開されているので、myVMwareからダウンロードします。 中身はvAppでVMが2台（分析用、UI用）で、このvAppをvCenterからデプロイします。
クラスタ組んでる環境にデプロイしようとするとDRSを有効にしていないとダメって怒られるんですけど、 ライセンス上DRS使えないEssentialsやStandaloneでもデプロイできます。下記参照。
- vAppをデプロイするホストを1台選んでメンテナンスモードにし、クラスタから除外する
- メンテナンスモードをそのホストにデプロイする。（vAppとしては展開されない）このときVM2台に対して静的IPを付与する
- VM2台を起動する
- ホストをクラスタに戻す
vCenterがAD連携していたのですが、ログインもADアカウントでいけました。
注意
このVM2台でけっこうリソース食うんですね。↓にもありますが、HDDも2台で約350GBくらい。 リソース分析も必要だとは思うんですが、正直ここまでのHWサイジングしてなかったので苦しい。。。
VMware KB: vRealize Operations Manager 6.0 Sizing Guidelines
VCP5更新できた...はず
vmware certified professional - Data Center Virtualization 5
本当は3月で有効期限を迎えてたんですけど、5/8まで延長されていたので気合入れて勉強しました。せっかく5日間研修行ったのに失効するのはやはりもったいない。。。 一発勝負だったんですけど無事受かって良かったです。 合格証書と認定サイトでのステータスが更新されていないとまだホントに更新できてるか安心できないですけどｗ
参考書はこちら
- 作者: Scott Rowe,Nick Marshall
- 出版社/メーカー: 翔泳社
- 発売日: 2014/08/21
- メディア: Kindle版
- この商品を含むブログを見る
１ヶ月間かけて読んできましたけどこれはKindle版買うよりも紙で買ったほうがよかったかも。 それかもう少し大きいタブレット端末買うべきでした。大判の技術書は読みにくすぎる…
さて参考書の中身ですが、vmware環境を設計する上で「なぜそうすべきか」という技術の裏付けもされていたので理解しやすい良書だと思います。 900pあるので実はまだ全部読めていないんですが。。。
vSphereのテクノロジでだけ通用するものも多いですが、ESXiのディレクトリ構成やDCUIでの操作、Auto Deployの技術なんかは、RedHat系Linuxに通じるところが多々あるし（Auto Deploy→PXE + kickstartによる自動インストール）、ネットワーク系の技術は一般的なL2,L3スイッチ周りの知識があればいけるかなと。
これから設計・構築が待ってるので、しっかり応用したいと思います。
次は高度情報技術者のネスペでしょうか。DBスペシャリストも気になりますが。
在庫管理のこと 〜 概要
棚卸とか倉庫移動とかいうキーワードに弱いので勉強を始めたぞい。
- 作者: ITC総合研究所
- 出版社/メーカー: 日本実業出版社
- 発売日: 2009/09/10
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 23回
- この商品を含むブログ (1件) を見る
書店で見つけてパラ見したらかなり良さそうな内容だったので買ってみた。 用語は慣れないところがあるけれども、在庫に対する考え方はわかりやすくてよい。
在庫管理とは何か
在庫（将来的に売ることを目的として自社で保有しているモノ）を正確かつ適正に管理をすること
なぜ（正確かつ適正に）在庫管理するのか
利益を上げるため
在庫が不足（欠品）すると...
- 商品を買いたい人が買えない
- 商品が無い店だと思われて客足が遠のく
- 納期を守れない会社だと思われて受注が減る
在庫があれば手に入るはずのお金が消えてなくなり、将来的な売上まで減ってしまう
在庫が過剰になると…
- 売ってもすぐに無くならないため、商品の鮮度（価値）が下がる
- 無駄に場所をとるため、維持コストがかかる
- 商品がリニューアルしたときには売れなくなって余ってしまう
- お金へとすぐに変えられないため、投資家から経営効率の悪い会社とみなされて敬遠される
在庫は多すぎても少なすぎてもダメ。
お客さんが欲しいモノを 欲しいときに 欲しい分量だけ、届けることができるように在庫は正確かつ適正に管理しなくてはいけない。 そのために、需要の先読みから始まって、商品の生産→売り場への到着までの時間やコストの計算が必要になる。
これが数千レベルになってくると正直考えただけでもお手上げな感じだし、多くの企業で在庫管理がうまくいかないって言われているだけある。 逆に、在庫管理に成功する（＝無駄が削減できている）なら、他の会社との競争でも優位に立てる。
SQLアンチパターンその７ マルチカラムアトリビュート
６章がちょっと書きにくいので、とばします！
マルチカラムアトリビュートとは
「複数列の属性」の名前の通り、１つのレコードの中で「２つ目の住所」「３つ目のメールアドレス」のような複数存在する可能性がある属性のこと。 テーブルの列数は可変にできないけれど、一体いくつ用意しておけばいいのか予測不能！
CREATE TABLE Customer ( customer_id INT UNSIGNED NOT NULL, name VARCHAR(1000), address1 VARCHAR(20), address2 VARCHAR(20), address3 VARCHAR(20), ... PRIMARY KEY (customer_id) );
いつ起こるのか
テーブルを設計するときに、属性として「複数」登録できそうな列があったとき。 いくつまで用意しておけばいいのかと思ったら怪しい。
何をしてはいけないのか（アンチパターン）
複数の列を定義すること。
何故ダメなのか
- 上限を超えたときに詰む
言わずもがな
SELECT * FROM Customer WHERE address1 = 'sample@gmail.com' OR address2 = 'sample@gmail.com' OR address3 = 'sample@gmail.com'
属性に値を追加・更新・削除するときにはもっと面倒なことになる
address1, address2, address3に空きがあるか？
- 空いている列に値を入れようとしている間に別のユーザが更新している可能性は？
- 追加・更新された値がレコード内で一意になっているか？
SQLが複雑になること必至
いい解決策は
従属テーブルを作る
CREATE TABLE Customer ( customer_id INT NOT NULL, name VARCHAR(1000), address1 VARCHAR(20), address2 VARCHAR(20), address3 VARCHAR(20), ... PRIMARY KEY (customer_id) ); CREATE TABLE Customer_Address ( customer_id INT NOT NULL, address VARCHAR(20) NOT NULL, PRIMARY KEY (customer_id, address), FOREIGN KEY ( customer_id ) REFERENCES Customer(customer_id) ON DELETE CASCADE ON UPDATE CASCADE, );
これで上限気にせずに追加ができるし、検索も楽
SELECT * FROM Customer AS c INNER JOIN Customer_Address AS ca ON c.customer_id = ca.customer_id WHERE c.address = 'sample@gmail.com'
「列増やすなら行増やせ」
