blog.toxn

あしあと

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 はインプレースアップグレードができます。

  1. vCSAをアップグレードする
  2. ホストをアップグレードする
  3. 仮想マシンをアップグレードする

vCSAをアップグレードする

公式の手順スライドがあったので参考にしました。助かります。

featurewalkthrough.vmware.com

まずは、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パススルー、シリアルポートが強化されるようですが、 今のところ足りているので、すぐにはアップグレードしないかなぁ。。。

vSphere 6.0 Documentation Center

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でもデプロイできます。下記参照。

kb.vmware.com

  1. vAppをデプロイするホストを1台選んでメンテナンスモードにし、クラスタから除外する
  2. メンテナンスモードをそのホストにデプロイする。(vAppとしては展開されない)このときVM2台に対して静的IPを付与する
  3. VM2台を起動する
  4. ホストをクラスタに戻す

vCenterがAD連携していたのですが、ログインもADアカウントでいけました。

注意

このVM2台でけっこうリソース食うんですね。↓にもありますが、HDDも2台で約350GBくらい。 リソース分析も必要だとは思うんですが、正直ここまでのHWサイジングしてなかったので苦しい。。。

VMware KB: vRealize Operations Manager 6.0 Sizing Guidelines

VS2015ではIf演算子がイイ感じになってた

toxn.hatenablog.com

のエントリの続きです。

続きを読む

CTF for ビギナーズ 2015 長野に行ってきた

お疲れ様でした。 SECCON 2015のまえに、リハビリと弱点解消のために行ってきました。

ctf4b.doorkeeper.jp

続きを読む

VCP5更新できた...はず

vmware certified professional - Data Center Virtualization 5

本当は3月で有効期限を迎えてたんですけど、5/8まで延長されていたので気合入れて勉強しました。せっかく5日間研修行ったのに失効するのはやはりもったいない。。。 一発勝負だったんですけど無事受かって良かったです。 合格証書と認定サイトでのステータスが更新されていないとまだホントに更新できてるか安心できないですけどw

参考書はこちら

マスタリングVMware vSphere 5.5

マスタリングVMware vSphere 5.5

1ヶ月間かけて読んできましたけどこれはKindle版買うよりも紙で買ったほうがよかったかも。 それかもう少し大きいタブレット端末買うべきでした。大判の技術書は読みにくすぎる…

さて参考書の中身ですが、vmware環境を設計する上で「なぜそうすべきか」という技術の裏付けもされていたので理解しやすい良書だと思います。 900pあるので実はまだ全部読めていないんですが。。。

vSphereのテクノロジでだけ通用するものも多いですが、ESXiのディレクトリ構成やDCUIでの操作、Auto Deployの技術なんかは、RedHatLinuxに通じるところが多々あるし(Auto Deploy→PXE + kickstartによる自動インストール)、ネットワーク系の技術は一般的なL2,L3スイッチ周りの知識があればいけるかなと。

これから設計・構築が待ってるので、しっかり応用したいと思います。

次は高度情報技術者のネスペでしょうか。DBスペシャリストも気になりますが。

在庫管理のこと 〜 概要

棚卸とか倉庫移動とかいうキーワードに弱いので勉強を始めたぞい。

SEがはじめて学ぶ在庫管理

SEがはじめて学ぶ在庫管理

書店で見つけてパラ見したらかなり良さそうな内容だったので買ってみた。 用語は慣れないところがあるけれども、在庫に対する考え方はわかりやすくてよい。

在庫管理とは何か

在庫(将来的に売ることを目的として自社で保有しているモノ)を正確かつ適正に管理をすること

なぜ(正確かつ適正に)在庫管理するのか

利益を上げるため

在庫が不足(欠品)すると...

  • 商品を買いたい人が買えない
  • 商品が無い店だと思われて客足が遠のく
  • 納期を守れない会社だと思われて受注が減る

在庫があれば手に入るはずのお金が消えてなくなり、将来的な売上まで減ってしまう

在庫が過剰になると…

  • 売ってもすぐに無くならないため、商品の鮮度(価値)が下がる
  • 無駄に場所をとるため、維持コストがかかる
  • 商品がリニューアルしたときには売れなくなって余ってしまう
  • お金へとすぐに変えられないため、投資家から経営効率の悪い会社とみなされて敬遠される

在庫は多すぎても少なすぎてもダメ。

お客さんが欲しいモノを 欲しいときに 欲しい分量だけ、届けることができるように在庫は正確かつ適正に管理しなくてはいけない。 そのために、需要の先読みから始まって、商品の生産→売り場への到着までの時間やコストの計算が必要になる。

これが数千レベルになってくると正直考えただけでもお手上げな感じだし、多くの企業で在庫管理がうまくいかないって言われているだけある。 逆に、在庫管理に成功する(=無駄が削減できている)なら、他の会社との競争でも優位に立てる。

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 = 'toxn12@gmail.com'
   OR address2 = 'toxn12@gmail.com'
   OR address3 = 'toxn12@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 = 'toxn12@gmail.com'

「列増やすなら行増やせ」