1. はじめに

1.1. このマニュアルについて

本書では、『CO-Store 5.0』の利用方法を説明します。

なお、本製品の動作環境やインストール方法については、 「CO-Store 5.0 インストール マニュアル 」をご確認ください。

1.2. 用語

本製品の呼称を省略し『CO-Store』と記載しています。

『Citrix Provisioning Services』(7.18 まで)、『Citrix Provisioning』(1808 (7.19) 以降) を 『PVS』と記載しています。

1.3. 免責事項

製品仕様は、改良のため、予告なしに変更する場合があります。 本製品を利用したことによるいかなる損害も弊社はその責を負いません。

詳しくは、CO-Store のインストーラーで示される「使用許諾契約書」をご覧ください。

1.4. CO-Store におけるシステム管理の基本的な手順

以下の 1 ～ 4 の作業の繰り返しが、ネットブートシステムにおける管理の基本的な流れになります。 CO-Store なら、1 ～ 4 のルーティンは自動化できます。

  1. サーバー上のディスクの更新をします
システム管理におけるもっとも大切な作業です。
サービスとセキュリティ維持のため欠かせません。

※ 更新が手間要らず。頻繁な更新が可能に。
  1. ディスクを端末に割り当てます (直感的なディスク・端末管理)
ディスクの配信先端末を指定します。
端末は次回から更新後のディスクで起動します。

※ 問題が生じたら 1 に戻ってやり直すのは簡単です。
  1. 日常の運用管理をします (直感的なディスク・端末管理)
システム上の全端末をコンソールから管理できます。
  1. ディスクの更新の必要が生じます
サービスの追加、ソフトウェアの導入、セキュリティ対策など、様々な理由からディスク更新の必要が生じます。

(1 に戻って、以下繰り返し...)

1.5. CO-Store システムの構成要素

1.5.1. システムの構成要素

CO-Store システムは、以下の要素から構成されています。

_images/system-overview.png
PVS サーバー
PVS（Citrix Provisioning Services, Citrix Provisioning）サーバー機能は、Citrix 社の Xen App & Desktop (Virtual Apps and Desktops) のコンポーネントとして提供されます。
原則として PVS サーバーは 1 サイトにつき 2 台以上必要です（「サイト」については、PVS 上の管理区分 参照）。
CO-Store
PVS サーバー上にインストールされ、「CO-Store コンソール」と「CO-Store サーバー」により構成されます。
（CO-Store サーバーは「CO-Store サーバー」「CO-Store 設定ウィザード」の 2 つのモジュールから構成されています）。
その他のサーバー
Active Directory DC、SQL サーバー、DHCP サーバー、TFTP サーバー、Citrix ライセンス サーバー、CO-CONV ライセンス サーバーが必要です。

1.5.2. PVS サーバーの役割

PVS サーバーは、Citrix 社の提供するネットブート型シンクライアント システム ソリューションを構築するためのサーバーです。
クライアント端末のシステムドライブを仮想化して、サーバーに集約管理することで、起動イメージを複数のクライアント端末で共有できるようにし、システムの管理性を飛躍的に高めます。

1.5.3. CO-Store サーバーの役割

CO-Store サーバーは、PVS サーバー上でサービス（Windows Server 上の常駐プログラム）として動作します。 CO-Store コンソールからの指示に従って PVS SOAP サービスに接続し、vDisk の更新処理を実行する、端末の割り当てを行う、といった働きを担います。

また、常にすべての PVS サーバーで負荷分散してディスク イメージを端末に配信できるようにディスクを管理する役割を果たします。 更新作業などで新しいバージョンが追加された直後からすべての PVS サーバーで負荷分散されます。

さらに、サーバーやネットワーク障害で利用できないサーバーが発生した時には、端末を別のサーバーに切り換えるなどの作業を行います。

1.5.4. CO-Store コンソールの役割

CO-Store コンソールは、ディスクイメージの更新、端末の割り当て、端末の起動といった日常的に使う管理作業を行うための、CO-Store の管理ツールです。 PVS サーバーの 1 台 (以上) にインストールされ、Windows アプリケーションとして動作します。

コンソールの使用法については、次章以下で詳細に解説します。

1.6. CO-Store におけるディスク管理のしくみ

1.6.1. CO-Store におけるディスクイメージの管理方法

CO-Store では、端末の起動環境を仮想化したディスク イメージを作成し、それぞれのイメージを時系列にそって世代管理します。
(このマニュアルで単に「ディスク」と呼ぶ場合にはこのディスク イメージを指します。)

また、ディスクの更新によって区切られる時系列の区分を「バージョン」と呼んでいます。

それぞれのディスクは独立して管理できるため、必要とする環境の種類数だけディスクを作成することで、 必要に応じた端末環境を提供することができます。

ただし、アップデートなどの管理作業はディスクごとに行う必要があるため、 ディスクごとの更新作業でストレージ (PVS サーバー上のディスク) を消費することになります。

ストレージのディスク サイズは CO-Store を運用するディスクの種類数、端末が利用する ディスクイメージの C ドライブの容量、およびサーバー側で何世代保持するのかにより変化します。 運用途中で変更することが困難な例が多いため、余裕のある容量を設定されることをお奨めします。

(CO-Colors いか 構成ガイド - ストレージ を参照してください。)

1.6.2. CO-Store でのバージョン管理のしくみ

CO-Store は独自技術による特徴的なバージョン管理方法を採用しています。

■ 差分管理の概要

CO-Store では、PVS の「差分ディスク」管理機能を利用してディスクのバージョン管理を行います。

たとえば、disk.vhdx というディスクをバージョン 0 からバージョン 1 に更新する場合、 元のファイル disk.vhdx には変更を加えず、 更新された部分（差分）のみから構成される disk.1.avhdx という差分ファイルを作成します。 以下更新のたび同様に disk.2.avhdx, disk.3.avhdx ……というように差分ファイルを追加していきます。

これらの .vhdx, .avhdx といったファイルを「ディスク ファイル」と呼びます。

差分管理によって共通部分を重複して作成しないこととしたことで、データ容量を抑えつつ、 多数の世代管理ができるようになりました。

■ 差分ファイルの依存関係

差分ファイルは、それ自体は前バージョンとの差分のデータしか保持しないため、単独では機能せず、 それ以前のファイルと合算されることではじめてディスクの一部としての機能をはたします。 たとえば disk.2.avhd という差分ファイルは、バージョン 2 の作成に際して作成されますが、 それ以前のバージョン disk.vhd, disk.1.avhd と合わさることではじめて「バージョン 2 のディスク」として機能します。

このように、差分ファイルが以前のバージョンのディスクがなければ機能しない状態にあることを「依存関係」があると呼んでいます。

_images/01-152-1.png

■ 依存関係の解消処理（差分ファイルのマージ）

差分ファイルが増え、使用するファイル数が増加すると、処理速度の低下が懸念されるため CO-Store では 10 バージョンごとに自動的に依存関係を解消（マージ処理）します。

マージ処理では、蓄積した差分ファイルを集約して 1 ファイルに作り直します。バージョン 10 の作成時であれば、 バックグラウンドで差分 1 から 10 までのすべての内容を含んだ disk.10.avhd を作成し、既存の disk.10.avhd と置き換えます。

CO-Store ではこのマージ処理によって、ファイル数の増加を抑え、処理速度低下を回避しています。 なお、マージ前の差分ファイルはマージ後も保持されるため、マージ前の状態へのロールバックも可能です。

_images/01-152-2.png

■ 中間バージョンの削除

CO-Store では、不要になった中間バージョンを削除することができます。

各差分ファイルが依存関係にある場合はそのままでは中間バージョンの削除はできませんが、CO-Store では、 削除指令があった場合に自動的に依存関係を解消することで、中間バージョンを削除できるよう工夫しています。

_images/01-152-3.png

1.6.3. 新しいディスクの作成と、ディスク間の関係

■ 新しいディスクの作成

CO-Store コンソールから新しくディスクを作成する場合には、既存のディスクを複製することで行います (「「このバージョンから新しいディスクを作成」」 を参照)。 作成した「 子ディスク 」は「 親ディスク 」とは独立した別系列のディスクとしてあつかうことができます。 ただしデータ的には、子ディスクは親ディスクに対する差分ファイルとして構成され、親ディスクに依存します。

メモ

新規にディスクを作成したい場合には、PVS イメージ作成ウィザードもしくは PVS コンソールから行ってください。

■ 子ディスクの活用による容量節約と、親子関係の解消

ディスク間の親子関係を維持した場合には、共通部分のデータを子ディスクは持たないため、ストレージの容量を大幅に節約することができます。

一方で、親ディスクを削除できないといった不利益を避けるため、親子の依存関係を解消し、完全に独立したディスクの系列とすることも可能です (「「このバージョンから新しいディスクを作成」」を参照)。

メモ

「まずは依存関係のある状態で作成し、後日依存関係を解消する」という運用も可能です。

1.7. PVS サーバーについて

PVS サーバーは、CO-Store の動作基盤となるネットブート シンクライアント環境を提供します。

1.7.1. PVS サーバーの構成

PVS サーバーは「サイト」ごとに 2 台以上設置する必要があり、それぞれ以下の 3 種の役割のいずれかを指定します。

マスター サーバー
ディスクの更新を行うサーバーを「マスター サーバー」と呼びます。 マスター サーバーは 1 ストアにつき 1 台のみです（「ストア」については、PVS 上の管理区分 参照）。
スレーブ サーバー
直接ディスクの更新を行わず、マスター サーバーからレプリケートされたディスク ファイルの 実体を保持するサーバーを「スレーブ サーバー」と呼びます。 スレーブ サーバーは 1 サイトごとに原則として 1 台以上必要です。 複数台のスレーブ サーバーを設置することも可能です （なお、マスター サーバーとスレーブ サーバーを併せて「ストレージ付きサーバー」 (もしくは単に「ストレージ」) と呼ぶことがあります）。
追加サーバー
ストレージを持たない (ディスク ファイルの実体を持たない) 補助的なサーバーです。 冗長性を補いたい場合などに設置することができます。

上記 3 種類のサーバーを、ネットワークの構成、端末の配置に応じて適切な台数を設置し、 必要な処理能力を得られるように配置してください。

サーバーの必要台数は PVS サーバーの処理能力を基準として算出してください。 (CO-Colors いか 構成ガイド - サーバーの台数 を参照してください。)

なお、関連製品の「ReadCache システム」を導入すると、サーバーの必要台数を大幅に減らすことができます。 (ReadCache システム を参照してください。)

1.7.2. PVS サーバー間のデータの利用関係

ディスクの更新はマスターサーバーに対して実施されます。 マスター サーバーは常に最新のディスク ファイルを保持し、常に自身の保持するディスク ファイルを利用します。

マスターサーバー上のディスク ファイルが更新されると、冗長化のために CO-Store タスクキュー サービスに よってバックグラウンドでスレーブサーバーにコピー (「レプリケート」と呼びます) されます。

スレーブサーバーのディスク ファイルの利用方法はレプリケートの完了前後で異なります。

レプリケート完了前は、CIFS 共有を介してマスターサーバー上のディスク ファイルを利用します。 その結果、スレーブサーバーはマスターサーバーに施された更新をその直後から利用できることになり、 この点が CO-Store の大きな特長のひとつとなっています。

レプリケート完了後はスレーブサーバーは自身の保持するディスク ファイルを利用します。

追加サーバーはストレージを持たないため、他のサーバーのディスク ファイルを利用して稼働します。 (どのサーバー上のディスク ファイルを参照するかは設定が可能です。)

1.7.3. PVS 上の管理区分

PVS では「ファーム」、「サイト」、「ストア」といったシステムの区分概念を用いています。 このマニュアルでも触れることがあるため、ここでまとめて解説します。

これら以外の概念や用語については、PVS のドキュメント をご参照ください。

ファーム
PVS の管理するシステムの最上位の概念です。異なるファームの間では、ディスクの共有はできません。
複数のファームのある環境において、あるファームで更新しているディスクを別のファームでも利用したい場合は、ストア同期機能について の機能をご利用ください。
サイト
端末、サーバーをまとめた論理的なグループです。端末、サーバーは、それぞれ必ずいずれかの 1 つのサイトに所属し、複数のサイトに所属することはありません。
特定のサイトに所属する端末は、そのサイト内のサーバーのみを利用します。遅延のある遠隔地をそれぞれ 1 つのグループとして構成する場合などに利用されます。
ストア
ディスク管理の区分に対して設けられる単位です。
ディスク ファイルの保存場所に対応しています。

CO-Store では、ストアごとに「マスター サーバー」を指定することになります。

1.8. 制限事項

1.8.1. ファイル名の制限

CO-Store であつかわれるファイル名は、以下の制限を守ってください。(PVS のファイル名の制限と一部異なります。)

  • 文字数は 1 文字以上、46 文字以下
  • 系列名に使える文字は、\ , / , : , * , ? , " , < , > , | , . , @ の 11 種の記号が含まれていないこと

ReadCache をご利用の場合には、以下の制限となります。

  • 文字数は 1 文字以上、27 文字以下
  • 系列名に使える文字は、 "A" ～ "Z" , "0" ～ "9" と、 "_" , "&" , "#" , "%" , "+" , "-" , "." , "@" の 8 種類に制限されます
    • CO-Store のみの場合と比較すると、^ , ~ , ( , ) , { , } , [ , ] , ; , , ! , $ が追加で利用できなくなることにご注意ください。

1.8.2. PVS の機能に対する制限

PVS の機能の一部について、CO-Store との競合に伴う制限が生じます。

  • PVS コンソールから端末に対するディスクの割り当てを行わないようにしてください。
  • Private モードのディスクをあつかうことはできません。PVS のバージョン管理機能を有効にした上で Standard モードで運用してください。
    • WriteCache の種類は ハードディスクのオーバーフローありデバイス RAM にキャッシュ を推奨します。
  • PVS の「仮想環境を利用した自動更新」機能は利用できません。自動更新には、CO-Store の自動更新機能を利用してください。
  • vDisk のアクセス モードの「非同期 IO」 (PVS 1811 で追加) は利用できません。