4. 具体的な構成設計について

4.1. 端末の設計

まず、各端末でキャッシュに保持するディスクの種類数を検討してください。

ディスクの種類数が 1~2 程度の場合には、まずは端末の内蔵 SSD の容量は 128 GBとして検討してください。 ディスクの種類数が更に大きかったり、「Linux」「オフラインブート機能」を用いる場合には、256 GB ドライブのほうが適する場合があります。

128 GB ドライブの場合、目安としては NTFS 領域 55 GB 程度、ReadCache 領域 60 GB 程度 として使うことになります。 NTFS領域は、「ページング領域」「アプリケーションのワークエリア」に加えて、ネットブート環境の「WriteCache 領域」としても使われます。 オフラインブート機能を用いる際には、そのブートイメージも保持することになります (オフラインブート用のディスクイメージは通常 15~25 GB 程度であり、その 2~3 倍程度の容量が必要です)。

Linux を用いる場合には、「Linux 用の Swap 領域」 および 「Linux 用の ReadCache 領域」として ext4 領域を 20 GB 程度必要とします。もし128 GBドライブの場合には、目安としては NTFS 領域 55 GB 程度、ext4 領域 15 GB 程度、ReadCache 領域 45 GB 程度 として使うことになります。

端末の CPU および メモリの量は、任意に検討ください。

  • CPU は Core i3 でも十分高速に動作します(学習院大学の事例を参照のこと)。
  • メモリは 8 GB が標準と考えます(4 GB では多少さびしい?けど、学習院大学の事例では 4 GB です)。
  • 内蔵ディスクは、SSD を推奨します。上述の通り、容量は通常は 128 GB で十分です。
  • GPU は任意に選択してください。
  • 内蔵インタフェイスを用いた有線接続であることが必須です(無線でネットブートはできません)。

<< まとめ: 端末の設計 >>

  • CPU: 任意。Core i3 でも十分と感じるぐらいに高速になります。
  • メモリ: 8 GB 推奨。4 GBでも十分でしょうが、5 年使うことを考えると 8 GB がおすすめ。
  • ドライブ: SSD 推奨。
  • NIC: 端末内蔵のネットワークインタフェイスを用いた有線接続であることが必須。
  • UEFI 推奨。(BIOS よりも起動が早くなります)
  • 画面は大きく解像度の高いものの方が教育効果が高いと考えます。

4.2. ネットワークの設計

端末とサーバー間のネットワークは、有線接続であれば、帯域は通常は問題となりません。 200 MB のデータを各端末がサーバーから読み込むことがあると想定して、起動時間を推定してください。

端末とサーバー間のネットワークの通信遅延はほぼない状態にしてください。 同一キャンパス内の LAN であればほぼ問題ないと言えますが、1ms の遅延があると、端末起動時間等に数秒~数十秒の影響が出ることがあります。 もし、サーバーと端末間に遅延がある場合には、端末に近い位置にプロキシサーバーを設置することになります(京都産業大学の事例を参照のこと)。

ネットワークが切れた状態でも、なんとかして起動(オフライン起動)する必要がある場合には、別途「ローカルブートオプション」の導入を検討してください。 ただし、この場合には内蔵ディスクの容量を追加する必要が生じることがあります。

<<まとめ: ネットワークの設計>>

  • 有線接続であること
  • エッジの帯域は 100Mbps でも問題なく動作します
  • サーバーと端末間の通信に遅延があるときには、プロキシサーバーを設置する
  • どうしてもオフライン起動が必要なときには、ローカルブートオプションの導入を検討する

4.3. サーバーの設計

サーバーの台数

ネットワーク構成が標準的であれば、サーバーは常に 2 台ないし 3 台で十分です。 2 台では冗長性に不安があると考え 3 台にするケースもあれば、端末台数が 200~300 台程度であれば、コスト面を考えてサーバーを 2 台にするケースもあります。

遅延のあるネットワークや、極端に帯域の狭いネットワークがある場合には更に追加でプロキシサーバーの設置が必要となります (この場合の構成は別途お問い合わせください)。

<< まとめ: サーバーの台数 >>

2 ないし 3 台 (もちろん、これより多くても何ら困らない)

ストレージ

ネットブートサーバーの OS 部分(Windows Server) が利用するストレージは通常どおりに確保してください(通常は 300 GB 程度か?)。

次にディスクを保持するために利用するストレージ容量の検討にあたっては、まずはディスクの種類数を検討してください。 端末のハードウェア構成が異なると、ディスクを分けるものと考えてください。 異なるハードウェアに対してディスクを共通化することもできますが、実運用上はこの機能を用いないことをおすすめします。

次に、端末側における C ドライブの容量を検討してください。。 この容量は、端末の内蔵ドライブのサイズに関係なく検討できます。

最後に、サーバー上に保持したいバックアップの世代数を検討してください。 一般には 100 世代程度保持するのが適切と考えられます。

その上で、サーバーのディスク容量の計算式にはいくつかの算式があります。 算式では次の変数を利用します。

変数 意味
A ディスクの種類数
B ディスクが提供する C ドライブの容量 (GB)
C サーバー側に保持したいバックアップの世代数

C は 3~5 でよい場合

A × B × C (GB)

ディスク全体を保持すると考え、最悪のケースにおいても C 世代を保持できる容量となります。

C は 100 程度とする場合

A × ( B + C × 2) (GB)

1 回更新作業をするたびに、差分ディスクが2GB程度生じると考えての算式です。

なお、Linux を使う場合には、Linux イメージを管理するために「 +300~400 (GB) 」程度を追加してください。

<< まとめ: サーバーのストレージ >>

上記計算式に従い、できるだけ潤沢に割り当ててください。性能は問いません。

メモリ

ネットブートサーバーにおいて、全体の性能に最も直接的に影響するのがメモリーの量です。 メモリはストレージへの負荷を下げるためのキャッシュとして活用されます。 キャッシュの量は「ディスク 1 種類あたり 2 GB」が目安ですので、サーバーとしての動作に必要な 2 GB を含めて、ディスクの種類数が A 種類ということであれば、 「A × 2 + 2 (GB) 」 が必要容量です。

ネットブートサーバーに SQL サーバー機能を同居させる場合には、「 +4 (GB) 」 してください。

ネットブートサーバー上で「Hyper-V を用いたディスク更新機能」を利用する際には、「 +8 (GB) 」 してください。この機能は Windows 10 の Feature Upgrade を手軽に行うために必要となります。

Linux を使う場合には、さらに「 +8 (GB) 」 してください。NFS サーバーとして利用する Ubuntu 環境を動作させるために利用します。

<< まとめ: サーバーのメモリ >>

上記計算式に従い、できるだけ潤沢に割り当ててください。

通常は 24 GB 前後となります。端末台数が多いときには 64 GB といった事例もあります。

ネットワーク

まずは、サーバーに最も負荷がかかる(多数の端末が一斉起動する)際にどの程度の出力トラフィックが必要になるかを検討してください。

通常は、一斉起動すると想定される端末教室を列挙し、その教室上流のネットワーク帯域を積算したものとなります。

この帯域をサーバー台数で除した値が、サーバーに必要とされるネットワーク帯域となります。

なお、CPU が極端に遅かったりメモリが不足したりしない限りにおいては、サーバーの性能はネットワークインタフェイスの帯域により決まります (CPU が 6C/12T 程度あれば、10 GbE インタフェイスが埋まります)。

<< まとめ: サーバーのネットワーク >>

同時一斉起動する端末群に対して必要となる帯域から考える。

GbE×4 程度か、10 GbE を 1 本にしてしまうかが標準的な構成となります。

CPU

目安としては、ネットワーク帯域 1 Gbps に対して、 1C/2T 程度あれば 十分です。

ただし、ネットブートサーバーに SQL サーバー機能を同居させる場合には、「少なくとも 4C/4T 以上」としてください。

ネットブートサーバー上で「Hyper-V を用いたディスク更新機能」を利用する際には、「2C/2T」 程度を追加割り当てしてください。 この機能は Windows 10 の Feature Upgrade を手軽に行うために必要となります。

Linux を使う場合には、さらに「1C/2T」程度を追加割り当てしてください。 NFS サーバーとして利用する Ubuntu 環境を動作させるために利用します。

<< まとめ: サーバーの CPU >>

通常は 6C/12T もあれば問題ありません (1way で十分)。

物理か仮想か

前述の通り、ネットブートの性能を最大限に引き出すためには、「メモリ容量を多く」「ディスク容量を多く」「ディスクの単価を下げる」のがコツとなります。 この要件は一般的な仮想化環境とは完全に逆行した要件となるため、「仮想サーバーでネットブートサーバーを構成すると高くつく」ことになりがちです。

また、ネットブートサーバーは瞬間的に10GbEを埋めるようなトラフィックを発生させることがあります。仮想化基盤を共有する他のサービスに影響を与えないためにも、物理を選択することをおすすめしています。

<< まとめ: サーバーは物理か仮想か >>

どちらでもいいが、物理を推奨する