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日間研修行ったのに失効するのはやはりもったいない。。。 一発勝負だったんですけど無事受かって良かったです。 合格証書と認定サイトでのステータスが更新されていないとまだホントに更新できてるか安心できないですけどw
参考書はこちら
- 作者: Scott Rowe,Nick Marshall
- 出版社/メーカー: 翔泳社
- 発売日: 2014/08/21
- メディア: Kindle版
- この商品を含むブログを見る
1ヶ月間かけて読んできましたけどこれは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アンチパターンその7 マルチカラムアトリビュート
6章がちょっと書きにくいので、とばします!
マルチカラムアトリビュートとは
「複数列の属性」の名前の通り、1つのレコードの中で「2つ目の住所」「3つ目のメールアドレス」のような複数存在する可能性がある属性のこと。 テーブルの列数は可変にできないけれど、一体いくつ用意しておけばいいのか予測不能!
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'
「列増やすなら行増やせ」
SQLアンチパターンその5 EAV(エンティティ・アトリビュート・バリュー)
EAV(エンティティ・アトリビュート・バリュー)とは
Attribute(属性)とValue(値)のペアを1行として登録すること。
CREATE TABLE Products ( product_id BIGINT UNSIGNED NOT NULL, name VARCHAR(100), PRIMARY KEY (product_id) ); CREATE TABLE Product_attributes ( product_id BIGINT UNSIGNED NOT NULL, attribute_name VARCHAR(100) NOT NULL, attribute_value VARCHAR(100), PRIMARY KEY (product_id, attribute_name), FOREIGN KEY (product_id) REFERENCES Products(product_id) );
(product_id, name) ------------------ (1, "hogehoge") (product_id, attribute, value) ------------------------------ (1, "brand", "NB") (1, "country", "japan") (1, "custom1", "piyo")
いつ起こるのか
可変属性のサポート。テーブルの設計変更を柔軟にしようとする
何をしてはいけないのか(アンチパターン)
汎用的な属性(EAV)テーブルを作ること
何故ダメなのか
- 属性値の取得クエリの明確さが低下する。
-- 従来のやりかた SELECT product_id, brand FROM Products;
-- EAVでのやりかた SELECT product_id, attribute_value AS brand FROM Product_attributes WHERE attribute_name = 'brand';
- 適切なデータ型が使用できなくなる。
- NOT NULL制約、CHECK制約、FOREIGN KEY制約が使えなくなる。
可変な属性に対応すると、どんな値が入っても良い=列ごとに設定するべき制約を設定できなくなる。
- 本来1行だった行を作り直すのが大変。
SELECT p.product_id, a1.attribute_value AS brand, a2.attribute_value AS country, a3.attribute_value AS custom1 FROM Products AS p LEFT OUTER JOIN Product_attributes AS a1 ON p.product_id = a1.product_id AND a1.attribute_name = 'brand' LEFT OUTER JOIN Product_attributes AS a2 ON p.product_id = a2.product_id AND a2.attribute_name = 'country' LEFT OUTER JOIN Product_attributes AS a3 ON p.product_id = a3.product_id AND a3.attribute_name = 'custom1' WHERE p.product_id = 1;
いい解決策は
- テーブル継承
- 準構造化データ
- アプリで頑張る
テーブル継承には以下の方法がある。いずれもOOPの継承の概念をテーブルで表現したもの。
- 単一テーブル継承(STI ... Single Table Inheritance)
- 具象テーブル継承
- クラステーブル継承
単一テーブル継承は、サブクラスのメンバ(列)をすべて一つのテーブルに含む方法。共通部(親クラスメンバ)を除き、行毎にタイプが異なるため、ある行で値を持たない列にはNULLが入る。
具象テーブル継承は、サブタイプ毎にテーブルを作成し、共通列もそれぞれで持つ方法。
クラステーブル継承は、サブタイプのメンバだけを持つテーブルを新たに作り、親テーブルからの参照を張る方法。これは垂直分割であり、テーブルの正規化をするときの方法。
準構造化データ JSONとかXML形式のデータをBLOB型の列として持つ。 アプリ側でパースして、内容のチェックが必要になるため、DBに頼らずアプリで頑張る方法。
アプリで頑張る フレームワークによってはEAVを使っている場合もあるし、使わざるを得ない場合もある。その時は型チェックとか諸々をアプリで頑張る。
NULLの話も後で出てくるんですが、新たな属性が必要になったときは列を追加する=STIでいく のがよいかと。 ワイルドカードを使わない、NULLの扱い方をちゃんと意識するというのを守れていればーですけど。