Azureを触ってみようということで、書籍をなぞってみる。
参考書籍:
ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築
横山 哲也
メモ
- クラウドコンピューティング
-
煎じ詰めれば、サーバーの利用形態
一般的に認知されている定義はNIST(米国国立標準技術研究所)が公開した文書によるもの。上記文章引用:
2. NIST によるクラウドコンピューティングの定義
クラウドコンピューティングは、共用の構成可能なコンピューティングリソース(ネットワーク、サー バー、ストレージ、アプリケーション、サービス)の集積に、どこからでも、簡便に、必要に応じて、ネ ットワーク経由でアクセスすることを可能とするモデルであり、最小限の利用手続きまたはサービス プロバイダとのやりとりで速やかに割当てられ提供されるものである。 - サブスクリプション
-
Azureの課金の単位
コア数や共同管理者数、ストレージアカウント数などに制限がある
詳細は公式参照。
対応策としては、複数のサブスクリプションを運用するか、上限の引き上げを申請する。 - 管理ポータル
- 管理画面。AWSで言うところの、コンソール。
- Region / Data Center
-
基本的なことですが、地域とデータセンターです。
GeoもRegionと同義 - クラウドサービス
-
インターネットからのアクセスの単位
仮想マシンの「箱」に当たる
パプリックIPアドレスを1つ持ち、インターネットからアクセスできる。
クラウドサービス間のインスタンスのアクセスには、仮想ネットワークかインターネットを経由する必要がある。 - 仮想ネットワーク
-
仮想マシンを作る前に作成する必要がある。
注意点:クラシックポータルで、仮想ネットワークがない状態で仮想マシンを作成した場合は、 クラウドサービス内のみで利用可能なネットワークが構成されます。
- virtualの意味
-
面白いコラムだったのですが、virtualはどちらかと言うと「仮想」よりも「事実上の」と言う意味に近いそうです。
英語の「virtual」の第一義は「事実上の」で、例文として「virtual promise」が出ていました。これは「法的な形式は満たしていないけれども効力のある契約」の意味だそうです。
へー、知らなかった。
引用:横山 P20 - クラウドサービスのURL命名規則
-
ドキュメントでは見つからなかったですが、わざとエラーメッセージを表示させてみた。
This field can contain only letters, numbers, and hyphens. The first and last character in the field must be a letter or number. Trademarks, reserved words, and offensive words are not allowed.
- 文字
- 数字
- ハイフン※最初と最後には使えない
- Storageのレプリケーション
-
- Locally Redundant(LRS):同地域の同施設に3つの複製を作成
- Geo-Redundant(GRS):組み合わせが固定された別の地域に複製を作成:地域ごとに3つの複製を持ち、合計6つ
- Read-access Geo-Redundant(RA-GRS):Geo-Redundantの複製先は直接利用できないが、こちらは読み取りが可能となる
- Zone Redundant(ZRS):複数の地域・施設に複製を作成
参照:公式 - ストレージアカウントの主なサービス
-
- BLOB(Binary Large OBject
- Que
- Table
- File
- ブロックBLOB:連続再生に向いている
- ページBLOB:ランダムアクセスに最適化している
また、LRSはデータセンターレベルの障害でデータ損失の可能性がある(10年単位であるかないかだと思いますが)ので、MSとしてはGRSを推奨している。しかし、LRSが望ましいケースもあるとのこと。 - GRSのリージョンペア
-
GRSのセカンドリージョンは固定
東日本と西日本がペアです。今のところ、もう少し離れててもいいじゃないかと。。。 - 仮想マシンが持つ動的IPアドレス(DIP)
- DHCPサーバから割り当てられ、再起動するまでは同じ
- Virtual Machineの種別
-
TierとSizeで分別される。
Tier = Basic / Standard
Basicの方は、機能が一部省かれます。Azure ロード バランサーと自動スケーリング機能が提供されず、料金は最大で 27% 低く設定されています。
Size = CPU, Memory, Disk, GPUの組み合わせ
引用:Basic (基本) レベルの仮想マシン
Azureの仮想マシンのサイズを確認してみた- A-series
- A-series - compute-intensive instances
- Av2-series
- D-series
- Dv2-series
- DS-series*
- DSv2-series*
- F-series
- Fs-series*
- G-series
- GS-series*
- H-series
- N-series
F = Dv2シリーズと同じプロセッサを搭載しているものも、Dv2シリーズと比べ、コア当たりのメモリやローカルのSSD容量は小さい
Tier BASICで選べるのはA seiesのみ。 - RDMA
-
Remote Direct Memory Access
ダイレクトメモリアクセス(Direct Memory Access (DMA))は、CPUが介在することなく、ホストメモリへ直接アクセスを行うデバイスの機能である。 RDMA (Remote DMA)は、CPUが関与することなくネットワーク越しにリモート計算機上のメモリへアクセスする(すなわち、リモート計算機上のメモリからリードおよびリモート計算機上のメモリへライトする)機能である。
参考:SSD情報 - クラウドサービスのRDP時のポート
-
ランダムなポートが割り当てられる
通常はTCPの3389番 - RTM
-
Release To Manufacutre
完成品 - FCS
-
First Customer Shipment
最初の発送 - SysPrep
-
サーバ固有の情報を抜いて仮想マシンイメージを作ることができるツール
GUIもあるが、/move:vmオプションが使えない(HW検査を省略できない)
VMIからSysPrep済みかは分からないので、分かりやすいVMI名をつけないとハマる - windowsサーバで英語キーボードと認識される
-
結局解決策は分からず。。。
やっていること- 言語に日本語追加
- Dateを日本に変更
- Localeを日本に変更
- 標準キーボードのドライバを106/109(Ctrl+Eisu)に変更
- Mac RDPとMac RDP Betaの両方とも試す
- waagent
-
Sysprepと同様な機能を持つLinuxインスタンス向け構成管理ツール
sudo waagent -deprovision - VMI
-
Virtual Machine Image
旧Azureポータルだと少し分かりづらかった。
左カラム・VIRTUAL MACHINES → 右ウィンド・IMAGES - VMIからのWindowsインスタンスの作成
-
Tier / Size※ / ユーザ・PW / Cloud Service = 変更可能
Region / Storage Account = 変更不可 - Immutable Infrastructure / Disposal Infrastructure
-
本番環境のサーバ環境設定を継続的に変更を加えるのではなく、
開発環境で新しい環境を毎度作り、それを入れ替える形で都度展開するインフラの保守方式 - 99.95%のSLA
- 仮想マシン2台以上で冗長構成すると言う条件で99.95%
- Scaling Up
-
再起動を伴います。構成変わるから、しょうがないっすよね。
また、再起動に伴い、DHCPも振り直されます。
変更方法:インスタンスの詳細情報から、CONFIGUREタブでTier / Sizeを変更できます - Windows ServerのID
-
Local Security IDとDomain Security IDがあるみたいです
ここら辺は別途確認します。Win Server全然使ったことないからなぁ。。。 - Intel Xeon
-
はい、サーバ周りも強くないので、Xeonを調べました。
下記ページを参考にさせていただきました
CPUにXeonを使う意味や違いを初心者向けに解説
プロセッサだけでなく、ECC対応のメモリがないとパフォーマンスを引き出せないんですね - リソグラフィー(Lithography)
- 半導体の製造技術
- ECC対応メモリ
-
Error Check and Correctですか。
64bitごとに8bitの検出用データを付与して、
1bitは訂正、2bit以上でも検出はできる - 障害ドメイン
- 物理的サーバラックに近い
- 更新ドメイン
- アプリケーションの更新の単位
- 可用性セット
- 冗長構成を組むために使用する論理グループ
- Affinity Group
-
以前は使用されていた機能らしい
当初は、複数のサーバを立てた際に、物理的に遠い
(と言ってもデータセンター内でしょうが、、、)所に配備されていたそうです。
そのため、Affinity Groupと可用性セットを組み合わせることで、
「なるべく物理的に近い、異なる障害ドメインに複数のサーバを配備」することができたらしい。
今はAffinity Groupを設定しなくても、上記のように計らってくれる。
ちなみに、設定は、旧ポータルのSETTINGS → AFFINITY GROUPSに残っています。 - END POINT
- Stand Alone / Load-Balanced Set
- 動いているインスタンスのシリーズ変更
- 試してみましたが、できないみたいです
- ATAディスク
-
ATA / IDE / PATA はどれも同じものを指している。
SerialよりParallelの方が早そうなものですが、同期処理がオーバーヘッドになるそうです。
SATAがSerial-ATAだとは覚えていたが。。。 - TierがBASICだと可用性セットが使用できない
-
書いているそばから忘れていた
Load-Balanced Set End Pointが作成できなくてはまっていましたが、
TierがBASICだとロードバランサーが使えませんでした。 - Probe Protocol
-
HTTP or TCP
正常性確認のプロトコル
プロトコルに応じたポートとURLを指定する。
インターバルと回数で、「障害からダウン認定」と「復帰から正常認定」の最大時間が決まる - iSCSI
- IPネットワークでネットワークドライブを使用するためのプロトコル
- データ共有方法
-
- データベース接続
- ファイル共有
- ディスク共有
- データ複製
- ディスクの追加
-
デフォルトだとWindowsに対して1つしかディスクを追加できない?
追って確認します。
追記:問題なく実行できました。ディスク名変えてないという凡ミス。 - ホストキャッシュ
- Guest OSのキャッシュとは別に、Azure側でもつキャッシュ
- Azure Virtual Machine Diskの容量制限
- 1 - 1023 GBまで
Intel® Xeon® Processor E5-2660 (20M Cache, 2.20 GHz, 8.00 GT/s Intel® QPI)
0 件のコメント:
コメントを投稿