Linux 上の SQL Server 2019 コンテナー - Dell Technologies...Linux 上の SQL Server 2019コンテナー Dell EMC インフラストラクチャを使用したソフトウェア開発の事例

Linux上の SQL Server 2019 コンテナー Dell EMC インフラストラクチャを使用したソフトウェア開発の事例 2019年 8月

H17857

ホワイトペーパー

要約

このホワイトペーパーでは、Dell EMCプラットフォームでホストされているアプリケーション開発およびテスト環境用に Microsoft SQL Server 2019 コンテナーを使用するメリットについて説明します。

Dell EMC ソリューション

Copyright

2 Linux上の SQL Server 2019 コンテナー Dell EMC インフラストラクチャを使用したソフトウェア開発の事例に関するホワイトペーパー

この資料に記載される情報は、現状有姿の条件で提供されています。Dell Inc.は、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。

この資料に記載されているすべてのソフトウェアの使用、複製、頒布には適切なソフトウェアライセンスが必要です。

Copyright © 2019 Dell Inc. その関連会社。All rights reserved.（不許複製・禁無断転載） Dell Technologies、Dell、EMC、Dell EMC、および Dell または EMCが提供する製品及びサービスにかかる商標は Dell Inc.またはその関連会社の商標又は登録商標です。Intel、インテル、Intel ロゴ、Intel Insideロゴ、Xeonは、アメリカ合衆国および/またはその他の国における Intel Corporationの商標です。その他の商標は、各社の商標または登録商標です。 Published in the USA、08/19、ホワイトペーパー、H17857。

掲載される情報は、発信現在で正確な情報であり、予告なく変更される場合があります。

目次

Linux上の SQL Server 2019 コンテナー Dell EMC インフラストラクチャを使用したソフトウェア開発の事例ホワイトペーパー

3

目次

エグゼクティブサマリー ............................................................................................................................... 4

事例の概要 .............................................................................................................................................. 5

サポートするソフトウェアテクノロジー ............................................................................................................ 6

Dell EMCのサーバーとストレージ .............................................................................................................. 11

事例1：コンテナー化された開発/テスト環境の手動プロビジョニング ............................................................... 12

事例2：コンテナー化された開発/テスト環境の自動プロビジョニング ............................................................... 19

まとめ ..................................................................................................................................................... 28

今後について ........................................................................................................................................... 29

付録A：ソリューションのアーキテクチャとコンポーネントの仕様 ...................................................................... 30

付録B：コンテナーリソースの構成 ............................................................................................................ 34


エグゼクティブサマリー

エグゼクティブサマリー

ビジネスの課題

ソリューション概要

ドキュメントの目的

大規模なシステム向けに信頼できるトランザクション処理を実施することは、多くのソフトウェア開発者の能力をも

ってしてもなかなか実現できることではありません。しかし、商用のリレーショナルデータベース管理システム

（RDBMS）製品を使用することで、開発者はこれまでは不可能であった多くのアプリケーションを作成できるよう

になります。RDBMSを使用することでソフトウェア開発に関する多くの問題が解決されますが、その一方で、

RDBMS とアプリケーション間のコードおよびデータの整合性を確保する方法という長年の懸案が残ったままとなっ

ています。

特にコードとデータの状態管理に関しては、ソフトウェア開発およびテスト（開発/テスト）のライフサイクルにおける

頭の痛い問題です。アプリケーションではコードが追加され、変更されるため、テスターはデータベース内のコードとデ

ータについての既知の状態を把握しておく必要があります。例えば、既存のデータベースに 10件の顧客アカウントを

追加し、顧客の合計数をテストするようにテストを設計した場合、チームは常に同じ顧客ベースでテストを開始する

ように確認する必要があります。数百または数千のテストが含まれる大規模なアプリケーションでは、このアクティビテ

ィが経験豊富なチームにとっても課題となります。

コンテナーテクノロジーは、開発チームが従来の複雑性を排除しながら、分離されたアプリケーションを迅速にプロ

ビジョニングできる機能を備えています。生産性とタイムトゥバリューを向上させるため、多くの企業のソフトウェア

開発を手がける部門でコンテナーの使用が始まっています。通常は、マイクロサービスアーキテクチャをベースとする

アプリケーション用コンテナーのインストール、実装、使用から開始します。これまでは、コンテナー化されたアプリケ

ーションと Microsoft SQL Serverのようなデータベースサービスとの統合が、非常に労力のかかる作業となって

いました。迅速な開発プロセスにおいて遅延が発生することも多くありました。

このソリューションでは、SQL Server コンテナー、Kubernetes、Dell EMC XtremIO X2 コンテナーストレージイン

ターフェイス（CSI）プラグインを使用して開発プロセスを変革する方法について示しています。開発者は、オーケス

トレーションと自動化を使用して SQL Serverデータベースのセルフプロビジョニングを実行することで、生産性を向

上させるとともに、大幅な時間を節約することができます。

ソフトウェア開発/テスト市場がコンテナー上の SQL Server を使用して重大なビジネス上の課題を解決するための

一番の近道になると多くのアナリストが回答しているため、ここではソフトウェア開発/テストの事例に焦点を当ててい

くこととします。現在の SQL Serverの開発方法は、プラットフォームとツールが複雑に混在した状態で構成された

アプリケーションが出発点となっています。このプロセスは非常に複雑で、スケジュールの遅延とコストの超過を引き

起こす原因ともなります。IT プロフェッショナルにとってメリットとなり、ソフトウェア開発者にとってはマルチプラットフォー

ムで使いやすい環境となる方法を選ぶことで、干渉やリスクを最小限に抑えながら広く採用される可能性が高くな

ります。

このホワイトペーパーでは、Microsoft と SQL Serverのエコシステムで使用できる情報を拡張し、SQL Server コ

ンテナーを有効にすることでテスト/開発が享受するメリットに焦点を当てた 2つの事例を紹介していきます。さらに、

SQL Server 2019 Docker コンテナー、CSI仕様を実装する Kubernetes、および Dell EMC製品とサービスの

相互関係についても説明します。ここで紹介する事例は、開発者やその他のユーザーが XtremIO X2 ストレージ


5

事例の概要

アレイを使用して SQL Server コンテナーを簡単に使用できる方法を提示するために用意しています。

XtremIO X2 CSI プラグインを使用すると、サーバーからストレージまでの包括的な自動化とオーケストレ

ーションが可能になります。

対象読者

用語

フィードバックを歓迎いたします

このホワイトペーパーは、開発/テスト環境で SQL Server コンテナーを実装するメリットについて習得することに関心

を持っている ITプロフェッショナルを対象としています。

次の表では、このホワイトペーパーで使用される用語の一部を定義します。

表 1. 用語

用語説明

コンテナーアプリケーションとその依存関係を含む、分離されたオブジェクト。Dockerで実行されているプログラムは、Linux コンテナーとしてパッケージ化されています。コンテナーは広く承認された標準であるため、事前構築された多くのコンテナーイメージを Dockerの開発に使用できます。

クラスター Kubernetes クラスターは、ノードとして知られるマシンのセットです。1台のノードでクラスターを制御し、マスターノードとして指定します。残りのノードは、ワーカーノードとなります。Kubernetesマスターは、複数の社員に作業を分散し、クラスターの稼働状態を監視する役割を担います。

ノードノードでコンテナー化されたアプリケーションを実行します。物理マシンまたは仮想マシンのいずれかがノードとなります。Kubernetes クラスターには、物理マシンノードと仮想マシンノードを混在させることができます。

ポッドポッドは、Kubernetesの最小開発単位です。1つ以上のコンテナーと、アプリケーションの実行に必要な関連リソースの論理グループです。各ポッドはノード上で実行され、1つ以上のポッドを実行できます。Kubernetesマスターで、ポッドをクラスター内のノードに自動的に割り当てます。

Dell EMCでは、ソリューションやソリューションドキュメントへのご意見をお待ちしております。Dell EMC

Solutionsチームに E メールを送信するか、ドキュメントアンケートにコメントを記入してください。

作成者：Sam Lucido、Phil Hummel、Anil Papisetty、Karen Johnson

事例の概要

この事例では、Dell EMCプラットフォームでホストされているアプリケーション開発/テスト環境用に Microsoft SQL

Server 2019 コンテナーを使用するメリットについて説明します。両方の事例に対応したテスト環境は、Dell EMC

ラボでホストされていた 3台の Dell EMC PowerEdge R740サーバーと 1台の XtremIO X2 オールフラッシュスト

レージアレイで構成されていました。アーキテクチャ図とソリューションの構成の詳細については、「付録 A：ソリューシ

ョンのアーキテクチャとコンポーネントの仕様」を参照してください。

この事例では、Docker、Kubernetes、XtremIO X2 CSI プラグインで SQL Server開発のライフサイクルが

どのように加速していくのかを示します。このソリューションを使用すると、開発者はデータベースのインストールやス

トレージのプロビジョニングに関連する複雑な作業を行うことなく、SQL Server コンテナーデータベースを簡単に

プロビジョニングできるようになります。

mailto:[email protected]

https://www.surveymonkey.com/r/SolutionsSurveyExt


サポートするソフトウェアテクノロジー

事例 1の概要

事例 2の概要

事例の比較に関する概要

最初の事例では、多くの企業がコンテナーを使用して作業を開始する方法（Dockerのインストールと機能性の高い開発環境の

構築）から始めます。ここでの目標は、SQL Server コンテナーを迅速にプロビジョニングし、Dell EMC XtremIO X2ストレージ

アレイを使用して、サンプルデータベース（Microsoft の一般的な AdventureWorks データベース）のコピーを添付することです。

SQL AdventureWorks コンテナーを実行することで、Webブラウザーを使用してデータベースにアクセスし、一般的なエンタープラ

イズWebアプリケーションをシミュレートする方法について説明します。次に、コンテナーを削除して環境をクリーンアップし、次のスプ

リント用にリソースを空けます。

2つ目の事例では、Kubernetes用の XtremIO X2 CSIプラグインを使用してコンテナー化されたアプリケーションのプロセスを続

行し、開発/テスト環境の自動化レベルの向上と管理の簡易化を実現します。ここでは、手動によるストレージのプロビジョニングか

ら一歩進んで自動プロビジョニングへと移行していきます。開発者は Kubernetesを使用して、ローカルのプライベートレジストリー

から SQL コンテナーのプロビジョニングを制御し、XtremIO X2アレイからデータベースストレージを制御します。

AdventureWorksデータベースアプリケーションでの作業後、開発者は Kubernetesを使用してデータベースコードおよびデータ

の更新された状態を保護し、データベースの XtremIO仮想コピースナップショットを取り込みます。過負荷テストを十分に行った

後、開発者は Kubernetesおよび XtremIO仮想コピーを使用してデータベースを保存した状態にリストアします。テクニカルライ

ターは変更されたデータベースをプロビジョニングしてコードの変更を文書化し、開発者はコンテナーを削除して環境をクリーンアップ

します。

次の表に、2つの事例の比較に関する概要を示します。

表 2. 事例の比較


このセクションでは、このソリューションの重要なテクノロジーコンポーネントについてまとめます。

コンテナーベースの仮想化

仮想ハードウェア上でソフトウェアアプリケーションを有効にし実行するための 2つの主要な方式が、仮想マシン（VM）とハイパーバイ

ザーを使用する方式、およびコンテナーベースの仮想化（オペレーティングシステムの仮想化またはコンテナー化とも呼ばれる）を使用

する方式です。

1950年代に Burroughs Corporationによって最初に開発され、古くから幅広く普及している仮想化方式が、VM とハイパー

バイザーを使用する方式です。この方式は、1960年代初頭の IBM メインフレームの商用化とともに複製されました。IBM

VM/CMS、VMware ESXi、Microsoft Hyper-vなどのプラットフォームで使用される主な仮想化方式は、

アクション

事例 1：Dockerのみ事例 2：Kubernetesおよび

XtremIO X2 CSIプラグイン

SQL Server コンテナーのプロビジョニング

手動、スクリプトの使用セルフサービス（完全自動化） AdventureWorksデータベー

スのプロビジョニングストレージとオペレーティングシステムの管理者タスク

コンテナーと永続的なストレージの削除

手動、スクリプトの使用


7


コンピューターの物理コンポーネントを抽象化する、ハイパーバイザーレイヤーを使用する方式です。抽象化により、ゲストオペレー

ティングシステムを実行している複数の VMによるコンポーネントの共有を有効にします。最近開発されたのが、コンテナーベースの

仮想化です。これは、ホストオペレーティングシステム 1つで、仮想アプリケーションとして実行している複数のプロセスをサポートし

ます。

次の図は、コンテナーベースの仮想化と VMベースの仮想化を比較したものです。コンテナーベースの仮想化では、ゲストオペレー

ティングシステムのコンポーネントと分離されたソフトウェアアプリケーションの組み合わせによって、ホストサーバー上で実行されるコ

ンテナーを「アプリケーション 1」ボックス、「アプリケーション 2」ボックス、「アプリケーション 3」ボックスのように構成します。

図 1：主な仮想化方式

どちらのタイプの仮想化も、同時に複数のユーザーとアプリケーションをサポートすることで、コンピューターハードウェアへ

の投資効率を向上させるために開発されました。

コンテナー化によってアプリケーションの移植性が簡素化されるため、IT運用の生産性がさらに向上します。アプリケーション開発者

は、プログラムが実行されるサーバー環境以外の場所で作業を行うことが多くあります。ライブラリーのバージョン、依存関係、構成

設定の競合を最小限に抑えるため、開発者は開発、テスト、および本番前の統合用に本番稼働環境を複数回再作成する必

要があります。コアオペレーティングシステムがアプリケーションコンテナーとは別に構成できることから、ITプロフェッショナルは、複数

の環境にわたって整合性を維持したままコンテナーを簡単に導入できることを発見しました。

Docker コンテナー

UNIXオペレーティングシステムが 1970年初頭に一般公開されたときに、コンテナーベースの仮想化の開発につながる概念が登

場しました。コンテナー技術の開発は、Solomon Hykesがオープンソースコミュニティーに Docker コードベースをリリースした

2013年まで、多くの方面で展開されていました。Dockerエコシステムは、アプリケーションコンテナーを定義および構築し、ランタ

イム環境とホストオペレーティングシステムの間のやり取りを管理するためのツールとともにコンテナーのランタイム環境を構成する

要素となります。

2つの Docker ランタイム環境（Community Edition と Enterprise Edition）を使用できます。Community Editionは無料

で提供され、ベストエフォート型のコミュニティーサポートが付属しています。この事例のテストでは、Enterprise Editionを使用し

ます。これは、本番環境やビジネスクリティカルな状況で Dockerを使用しているほとんどの組織に適しています。Enterprise

Editionでは、環境内のコア数に基づいたライセンスの購入が必要となります。組織には、ライセンス登録された Docker ランタイム

とライセンス未登録の Docker ランタイムが存在する可能性があります。



また、サポートが不可欠な環境に適切なバージョンが確実に導入されるように、保護対策を講じておく必要があります。

Dockerレジストリーは、Docker イメージをセントラルリポジトリで格納し、提供するために使用されるテクノロジーをサポートしてい

ます。レジストリーは Docker Hubなどのパブリックにするか、プライベートにすることができます。Dockerユーザーは、Docker Hub

から圧縮されたイメージをダウンロードしてローカルレジストリーをインストールします。このイメージには、ゲストオペレーティングシス

テムおよびアプリケーションに固有の、必要なコンテナーコンポーネントがすべて含まれています。インターネット接続の速度と可用性

によっては、ローカルレジストリーを使用することで、イメージのダウンロード中の高レイテンシーを含め、パブリックレジストリーの使用

に関連する多くの問題を軽減できます。Docker Hubには、ユーザーがプライベートイメージをアップロードするためのオプションが用

意されています。ただし、ローカルプライベートレジストリーを使用すると、セキュリティが向上し、導入時のレイテンシーを低減できま

す。

プライベートレジストリーは、クラウドまたはローカルデータセンターに配置できます。プライベートレジストリーを配置する場所を決

定する際は、プロビジョニング速度とプロビジョニング頻度を考慮する必要があります。データセンターでホストされているプライベー

トレジストリーは、LANの速度と信頼性というメリットを活用できます。つまり、ほとんどの場合において、イメージを迅速にプロビジ

ョニングできます。この事例では、ローカルプライベートレジストリーを実装して、複雑性やクラウドでのホスティングにかかるコストを

排除した、迅速なプロビジョニングを実現しました。

Kubernetes 最新のアプリケーション：主に、依存関係や構成を使用してパッケージ化されたマイクロサービスが、コンテナーテクノロジーを使用

して構築されることが増えています。K8s とも呼ばれる Kubernetesは、コンテナー化されたアプリケーションを大規模に導入および

管理するためのオープンソースプラットフォームです。Kubernetes コンテナーオーケストレーションシステムは、2014年に Google

によってオープンソース化されました。

次の図に、Kubernetesのアーキテクチャを示します。

図 2： Kubernetesアーキテクチャ

https://hub.docker.com/search?q=restsql&type=image


9


大規模なコンテナーオーケストレーションに適した Kubernetesの機能は次のとおりです。

• コンテナーの自動拡張、レプリケーション、リカバリー

• IPの共有などコンテナー内の通信

• 複数のコンテナーを作成および管理するための単一エンティティ（ポッド）

• コンテナーリソースの使用率およびパフォーマンスの分析エージェント（cAdvisor）

• ネットワークプラグ対応のアーキテクチャ

• ロードバランシング

• ヘルスチェックサービス

事例 2でシミュレートされた開発/テストのシナリオでは、Kubernetes コンテナーオーケストレーションシステムを使用してポッドに 2つの Docker コンテナーを導入しました。

Kubernetesのコンテナーストレージインターフェイスの仕様

Kubernetesの CSI仕様は、オーケストレーションレイヤーを使用して、任意のブロックおよびファイルストレージシステムを、コン

テナー化されたワークロードに公開するための標準として開発されました。Kubernetesではこれまで、コア Kubernetes コードに

含まれ、コア Kubernetesバイナリーに同梱されていた強力なボリュームプラグインを提供していました。しかし、CSI を導入する

にあたり、コードが「ツリー内にある」ことが問題となり、Kubernetesへの新しいボリュームプラグインのサポートが追加されました。

Kubernetesにストレージシステムに対するサポートを追加するベンダーだけでなく、既存のボリュームプラグインで発生しているバ

グを修正するベンダーも、Kubernetesのリリースプロセスに合わせて調整を余儀なくされました。さらに、サードパーティ製ストレー

ジのコードによって、コア Kubernetesバイナリーの信頼性およびセキュリティに関する問題が発生しました。このコードでは、

Kubernetesのメンテナンス会社が管理およびテストを実施することが困難であるか、または不可能になることがほとんどでした。

CSI仕様を採用することで、Kubernetesのボリュームレイヤーが、真に拡張可能となります。サードパーティ製ストレージプロバイ

ダーは、CSIを使用してプラグインを記述および導入し、コア Kubernetes コードを一度も使用することなく Kubernetesで新しい

ストレージシステムを公開できます。

この機能により、Kubernetesユーザーのストレージオプションが増え、システムのセキュリティと信頼性を高めることができます。事

例 2では、Dell EMC XtremIO X2 CSIプラグインを使用して Kubernetesストレージの自動化のメリットを紹介しながら、

Kubernetesの利点について焦点を当てていきます。

Kubernetesストレージクラス

本紙で紹介する事例のいずれかで Kubernetes ストレージクラスを直接使用することはありませんが、Kubernetes ストレージクラスは、CSIおよび XtremIO X2 CSIプラグインと密接に関連しています。Kubernetesを使用すると、管理者はさまざまなレベル

のストレージ機能について説明し、サービス品質（QoS）のレベル、バックアップポリシー、その他ストレージ固有のサービスでこれ

らの機能を差別化することができるようになります。Kubernetes自体には、これらのクラスについて表す内容に関する固定された

意味はありません。他の管理システムでは、この概念をストレージプロファイルと呼ぶこともあります。

XtremIO X2 CSIプラグインによって、インストール時に Kubernetesに 3つのストレージクラスが作成されます。Kubernetes ダ

ッシュボードで表示できる XtremIO X2ストレージクラスは、事前定義されています。ユーザーは、これらのストレージクラスを使

用して、アレイ上に作成される永続的なストレージで使用可能な帯域幅を指定できます。次の表に、事前定義されたストレージ

クラスを示します。

https://kubernetes-csi.github.io/docs/introduction.html

https://www.dellemc.com/resources/ja-jp/asset/data-sheets/solutions/datasheet_xtremio-x2_csi-plugin_h17611.pdf

https://www.dellemc.com/resources/ja-jp/asset/data-sheets/solutions/datasheet_xtremio-x2_csi-plugin_h17611.pdf



表 3. XtremIO X2 CSIの定義済みストレージクラス

ストレージクラス GBあたりの MB/秒

高 15

中 5

低 1

要求されたストレージボリュームのサイズとストレージクラスで、指定する帯域幅を定義します。例えば、ストレージクラス「中」

で構成される 1,000 gibi（Gi）ストレージボリュームの帯域幅は、次のように算出します。

ストレージサイズ（1,000 Gi） x ストレージクラス（中クラス、GBあたり 5 MB/秒） = 合計帯域幅（5,000 MB/秒）

注：Giは、2つの同等の力（この事例では 10243）を示しています。

XtremIO X2の事前定義されたストレージクラスを使用すると、パフォーマンスの制限を定義して環境を効率的に拡張することが

できます。例えば、ストレージクラスが「低」の 100 コンテナーのプールでは、コンテナー化されたアプリケーションが割り当てられた帯

域幅を超えないように制限されます。このような制限によって、環境全体で信頼性の高いストレージパフォーマンスを維持すること

ができます。

QoSベースのストレージクラスを使用すると、コンテナー化されたアプリケーションによって消費されるリソースとストレージ帯域幅の

合計量のバランスを取ることができます。XtremIO X2 CSIプラグインによって作成されるストレージクラスよりも、よりカスタマイズ

されたクラスのセットを必要とするシナリオでは、Kubernetesで XtremIO X2 QoSを構成できます。カスタム QoSポリシーの作

成では、ギガバイトあたりの最大帯域幅、または最大 IOPS を定義できます。バーストパーセンテージを定義することもできます。

これは、コンテナーが一時的なパフォーマンスに使用できる最大制限を超える帯域幅または IOPSの量です。

事前定義されたストレージクラスとカスタマイズされた QoSポリシーを使用するメリットは、次のとおりです。

• 重要なアプリケーションに対して保証されるサービス

• 非本番環境のコンテナーにパフォーマンス制限を課すことにより、「ノイジーネイバー」問題を解消

Linux上の SQL ServerおよびDocker コンテナー

近年、Microsoftは、Linux オペレーティングシステムと互換性がある、または移植される製品のポートフォリオを拡張しています。例えば、Microsoftは、2016年 11月に Linuxで市販された SQL Server RDBMSの最初のバージョンをリリースしました。さ

らに最近では、SQL Server 2017のリリースに伴い、Microsoftが Docker コンテナーで SQL Serverを提供しました。SQL

server 2019の一環として開発中の、次世代 SQL Server for Linux コンテナーは、2019年秋のリリースを予定しています。

Microsoftは現在、Linux とWindowsの両方のホストで Linux コンテナーを実装し、WindowsではWindows コンテナーを実

装する SQL Serverを開発しています。これらの実装でサポートされる機能とロードマップはそれぞれ異なりますので、製品が要件

を満たしているかどうかを慎重に確認してください。本紙で使用するのは、以下のみとします。


11

Dell EMCのサーバーとストレージ

Linux向け SQL Server コンテナー。お使いの Kubernetes環境で最新の認定を受けた CSIプラグインが使用されていることを、

Dell EMCで確認することをお勧めします。

コンテナー化された Linux イメージの SQL Server 2017でのサポートを最初に導入したのは Microsoftです。Microsoftによれ

ば、SQL Server コンテナーを採用しているお客様の主な事例の 1つが、Kubernetesで処理された導入による DevOpsパイプ

ラインでのローカル開発/テスト用です。コンテナー内の SQL Serverは、環境全体での一貫性と信頼性のある独立した動作、使

いやすさ、簡単な起動と停止を実現するため、DevOpsにとって多くのメリットがあります。アプリケーションは、SQL Server コンテナ

ー上部に構築され、他の環境に影響を与えずに実行することができます。この分離によって、コンテナー内の SQL Serverが、テス

ト導入シナリオだけでなく DevOps プロセスにとっても最適となります。

Dell EMCのサーバーとストレージ

PowerEdgeサーバー

XtremIO X2ストレージ

Dell EMC PowerEdgeサーバーは、拡張性の高いビジネスアーキテクチャ、インテリジェントな自動化、統合されたセキュリティに

より、価値の高いデータ管理と分析のワークロードを実現します。オープンスタンダードの x86テクノロジーを基盤とする、ラック、タワ

ー、モジュラー型のサーバーインフラストラクチャの PowerEdgeポートフォリオにより、データセンターからクラウドへの拡張を迅速に

行うことができます。PowerEdgeサーバーは、すべての製品オプションに対して同一のユーザーエクスペリエンスおよび統合管理エ

クスペリエンスを提供します。したがって、すべての資産をパッチ、管理、アップデート、更新、廃棄するための一連のランブックを持っ

ておきます。

この事例では、PowerEdge R740サーバーを使用します。R740は、それぞれ最大 28個のコンピューティングコアを備えたインテルXeonスケーラブルプロセッサーを最大で 2つ搭載した 2Uフォームファクターです。このサービスは、企業への導入で最も普及している Linuxの各バージョン（Canonical Ubuntu、Red Hat Enterprise Linux、SUSE Linux Enterprise Server）をサポートしています。R740は、最も要求の厳しいデータベースおよび分析ワークロードを満たすために、さまざまなメモリー構成をサポートしていま

す。これには、最大速度 2,933 MT/秒の登録済み ECC DDR4 Load-Reduced DIMMS（LRDIMM）用に 24個の

スロットが含まれており、最大 3 TBまでメモリーを拡張できます。オンボードストレージは、最大 16 x 2.5インチの SAS/SATA

SSD（最大容量 122.88 TB）、または最大 8 x 3.5インチの SAS/SATAドライブ（最大容量 112 TB）を搭載したドライブベイを前面に構成できます。

本紙の事例で使用した PowerEdgeサーバーの構成の詳細については、「付録 A：ソリューションのアーキテクチャとコンポーネン

トの仕様」を参照してください。

Dell EMC XtremIO X2オールフラッシュアレイは、オンライントランザクション処理（OLTP）、オンライン分析処理（OLAP）、

混在ワークロードの実行に最適なストレージプラットフォームです。あらゆるサイズのデータベースに対して高い IOPS、超広視野

角帯域幅、一貫したミリ秒未満のレイテンシーを提供します。

注：PowerEdgeサーバーで XtremIO X2 オールフラッシュストレージを使用する SQL Serverソリューションの設計の詳細については、「Dell

EMC Ready Solutions for Microsoft SQL: Design for Dell EMC XtremIO」を参照してください。このガイドでは、SQL Server 2017のイ

ンスタンスを実行しているWindows Server 2016および Red Hat Enterprise Linux 7.6の両方で推奨される設計原理、構成のベストプラ

クティス、検証を行っています。ソリューションのテストでは、XtremIO X2アレイのレイテンシーが 500マイクロ秒未満を達成しましたが、一方で

XtremIO X2のスペックシートごとに達成可能な定格 22万の IOPS と比較して、72台のフラッシュドライブで 27万 5,000を超える IOPS を

サポートしていました。テストエンジニアは、XtremIO X2アレイが予想される IOPSの合計を超えた場合でもレイテンシーの大幅な増加がみら

れないことを発見しました。

https://www.dellemc.com/ja-jp/collaterals/unauth/technical-guides-support-information/solutions/h17593-ready-sql-xremio-ra.pdf




事例 1：コンテナー化された開発/テスト環境の手動プロビジョニング

この事例では、XtremIO X2ストレージアレイを使用して、Kubernetes/Docker環境における革新的な管理機能に焦点を当

てていきます。この事例では、DBAおよびシステム管理者が XtremIO/Kubernetes CSI 1.0プラグインを使用して、XtremIO

X2アレイでホストされている永続ストレージを含む SQL Server 2019 Linux コンテナーを導入する方法を説明します。

注：CSIプラグインを使用して Kubernetes クラスターに XtremIOストレージをプロビジョニングする方法の詳細については、「Dell

EMC XtremIO X2 Container Storage Interface Plugin Integration with Kubernetes」を参照してください。

事例 2では、XtremIO仮想コピーの使用について説明します。プロビジョニングでは、開発者は、AdventureWorksデータベース

の保護されたコピー、つまり「ゴールドマスター」を使用します。これは、XtremIO X2アレイ上で保持されます。XtremIO仮想コピ

ーによって、ゴールドマスターデータベースのプロビジョニングコピーを簡単に作成できます。この事例では、Kubernetesで

XtremIO仮想コピー機能を使用して AdventureWorksデータベースのコピーを作成します。この方法により、一貫性のあるデー

タベースの複数のコピーを簡単にプロビジョニングできるようになります。過負荷テストが完了すると、開発者は XtremIO仮想コピー

からデータベースをリストアします。


事例 1では、次の手順を実行してコンテナーベースの開発/テスト環境を手動でプロビジョニングします。

1. Red Hat Enterprise Linuxを実行している PowerEdge R740サーバーにDockerランタイムをインストールしま

す。

2. ローカルのプライベートDockerレジストリーをインストールして構成します。

3. 最新の SQL Server 2019 for Linuxコンテナーイメージを Docker Hubから取得します。

4. SQL Serverイメージをローカルプライベートレジストリーにプッシュします。

5. Docker Hubから軽量データアクセス層のコンテナーイメージを取得して、ローカルプライベートレジストリーにプッシュ

します。

6. Microsoft AdventureWorksデータベースファイルが格納されているストレージボリュームを構成し、Linuxバインドマウン

トを使用して、そのボリュームを SQL Serverコンテナーに接続します。

7. Webブラウザーで、データアクセス層のアプリケーションを使用して AdventureWorksデータベースへアクセスで

きることを確認します。

8. コンテナーを削除して、環境をクリーンアップします。

ステップ 1：Dockerのインストール

Docker コンテナーを使用して開発者の環境を作成するための最初のステップは、Docker ランタイムのライセンス取得とインス

トールです。

Docker管理者は、次のインストールコマンドを実行して Enterprise Editionをインストールします。

$ yum -y install docker-ee docker-ee-cli containerd.io

デフォルトでは、Docker コンテナーはすべてのホストメモリーにアクセスします。また、デフォルトでは、コンテナーはすべてのホス

トの CPUサイクルにもアクセスできます。Docker コンテナーにメモリーと CPUの制約を設定する方法の詳細については、

「付録 B：コンテナーリソースの構成」を参照してください。

https://hub.docker.com/r/dellemcstorage/csi-xtremio

https://www.dellemc.com/resources/ja-jp/asset/white-papers/solutions/white-paper_xtremio-x2_interface_plugin_for_kubernetes_h17583.pdf




13


ステップ 2：Docker レジストリーのインストール

ステップ 3：SQL Server 2019イメージの取得

開発/テスト環境を構築する際は、Dockerレジストリーの設定を考慮することが重要となります。Dockerレジストリーの設定

に影響を与える要素は次のとおりです。

• Variety（多様性）：レジストリー内のイメージの数

• Velocity（スピード）：アプリケーションをプロビジョニングする頻度

• Security（セキュリティ）：アプリケーションイメージの保護この事例では、多様性、スピード、セキュリティの主要な要件に対応するローカルプライベートレジストリーを使用します。

Docker Hubからローカルレジストリーを作成するには、開発者が次のコマンドを実行します。

$ docker pull registry $ mkdir -p /registry/private $ docker run -d -p 5000:5000 -name registry -v /var/lib/registry - -restart

Docker管理者は、Docker Hubから最新の Microsoft SQL Server イメージをローカルプライベートレジストリーにダウンロー

ドします。Docker管理者は、この SQL Server イメージに関して記載されたすべての要件が満たされていることを確認します。

この要件には、Dockerでサポートされるプラットフォーム上の Docker Engine 1.8以降と、最低 2 GBの RAMが含まれます。

注：信頼できるソースから高品質のコンテナーイメージにアクセスすることにより、Docker ファイルでローカルに作成されたイメージを作成および管

理するのに通常必要となる多くの労力を節約できます。コンテナーイメージの導入を試行する前に、必ず要件を確認してください。

イメージをダウンロードするには、Docker管理者が次の Docker pull コマンドを実行します。

$ docker pull mcr.microsoft.com/mssql/server

ステップ 4：SQL Serverイメージのローカルプライベートレジストリーへのプッシュ

ステップ 5：REST APIの取得とローカルプライベートレジストリーへのプッシュ

SQL Serverでローカルプライベート Dockerレジストリーを入力するには、Docker管理者が次の Docker

push コマンドを実行します。

$ docker push localhost:5000/sqlserver2019

注：SQL Server コンテナーイメージをカスタマイズする場合、お客様のビジネスの事例に応じて必要であれば、ベースイメージとカスタ

マイズの両方をローカルプライベートレジストリーに保存します。

このシミュレーション開発環境の一環として、開発者はシンプルな ASP.NET Core 2.0 REST API web アプリケーションプロトタ

イプを実装する軽量データアクセス層のコンテナーを使用します。SQL Server Management Objects（SMO）を使用すると、

プロトタイプはオンプレミス、Azure SQLデータベース、Azure SQL Data Warehouseを実行する SQL Server用の RESTful

インターフェイスを提供します。この HTTP クライアント向け軽量データアクセス層は、一般的な 3層データベースアプリケーション

設計をシミュレートしており、これにより開発者はWebベースのビジネスレポートを作成できるようになります。

https://hub.docker.com/_/registry

https://hub.docker.com/_/microsoft-mssql-server

https://github.com/sanagama/mssql-restapi





開発者は、次の Docker pull コマンドを実行して Github リポジトリからコンテナーイメージを取得します。

$ docker pull sanagama/mssql-restapi

開発者は、次の Docker push コマンドを実行して、イメージをローカルのプライベートレジストリーに保存します。

$ docker push localhost:5000/mssql-restapi

ステップ 6：ストレージボリュームの構成とコンテナーへの接続

マイクロサービスに使用されるコンテナーは、多くの場合、永続的なストレージを必要とせずに機能します。SQL Serverなどのデ

ータベースサーバーでは、多くの場合、コンテナーがシャットダウンまたは削除された後に保存する必要がある重要なデータに対し

て永続的なストレージが必要になります。

ストレージボリュームの構成

XtremIO X2から PowerEdgeサーバーに永続ボリュームを作成してマウントするには、次の 3つのステップが必要です。

1. ボリュームを 1つ以上作成する。

2. 1つ以上のイニシエーターグループを作成する。

3. イニシエーターグループにボリュームをマッピングする。

XtremIO X2アレイでストレージボリュームを作成する場合、管理者は、ストレージプールのドライブの数とタイプの定義など、一般

的に従来のストレージアレイに関連づけられている選択肢を選択する必要はありません。また、管理者は、RAID保護タイプを選

択する必要もありません。複数の XtremIO X2ボリュームにまたがるデータベースでは、アレイ上にコンシステンシーグループを作成

することを検討します。コンシステンシーグループは、スナップショットが要求されたとき、またはグループ内のディスクのレプリケーション

が行われるときに、書き込みの整合性を確保するためにグループ化されたボリュームのセットです。

注：XtremIO X2 ストレージのプロビジョニングは迅速かつ簡単ですが、このプロセスでは、ストレージ管理者と開発者の間で調整が必要です。

過去の例によると、外部ストレージを使用したコンテナーのプロビジョニングに対してこの調整を行うと、遅延が生じることがよくあり、開発に影響が

出ます。2つ目の事例では、チームで XtremIO X2向けの Kubernetesおよび CSIプラグインを使用してこれらの課題を解決する方法について

説明します。

永続ストレージのコンテナーへの接続

この最初の事例では、ストレージ管理者が Kubernetes および CSI プラグインを使用せずにストレージを管理します。したがって、

XtremIO X2ストレージを構成して PowerEdgeサーバーに接続した後、ストレージ管理者はストレージボリュームを SQL

Server コンテナーに手動で接続する必要があります。管理者は、Dockerボリュームまたは Linuxバインドマウントを使用して接

続を実行できます。


15


Dockerボリューム（コンテナーストレージ内）

Dockerボリュームは、Docker コンテナーで管理されるストレージを定義する機能を提供します。ストレージは、Dockerディレ

クトリー構造の下で保持され（例：

/var/lib/docker/volumes）、Docker CLIまたは Docker APIを通じて管理できます。ボリュームは Dockerエンジンによって管理され、次の図に示すように、ホストによる直接アクセスから分離されます。

図 3： Dockerボリューム

Dockerデータボリュームのメリットは次のとおりです。

• ボリュームは、Linux とWindowsの両方のコンテナーで機能します。

• ボリュームはコンテナー間で安全に共有できます。

• 新しいボリュームには、任意のコンテナーで事前入力したコンテンツを含めることができます。メリット

の完全なリストについては、Docker ドキュメントの「ボリューム」を参照してください。

Linuxバインドマウント（ホストストレージ内）

この事例では、Linux管理者が Linuxバインドマウントを使用して、SQL Server コンテナーをサーバーにすでにプロビジョニン

グされている XtremIO X2ストレージに接続します。Dockerガイドで説明したように、バインドマウントは高速なため、コンテナ

ーにストレージを接続する方法として最適です。次の図に示すように、バインドマウントはホストオペレーティングシステム内の任

意の場所に配置できますが、Dockerでは管理されません。

https://docs.docker.com/storage/volumes/



図 4：バインドマウント

Linux管理者は、次のコマンドを実行して XtremIO X2 sdbl

ディレクトリーを SQL Server コンテナーへマウントします。

$ cd /sdb1

$ mkdir mssql-data-dir $ mount -o bind /sdb1/mssql-data-dir /var/opt/

再起動後にデータを保全するため、Linux管理者は次のようにバインドマウントを使用して/etc/fstab ファイルを更新します。

/var/opt /sdb1/mssql-data-dir none bind 0 0

次に、Kubernetes管理者は-vパラメーターを使用して SQLボリュームを作成します。

$ docker run --name sqlservername -e “ACCEPT_EULA” -e “MSSQL_SA_PASSWORD=password” -v volumename:/var/opt/mssql-data-dir -p 1433:1433 -d localhost:5000/sql2019


17


バインドマウントは Docker の外部にあるため、外部プロセスまたは外部のユーザーがファイルを変更できます。Linux 上の

SQL Serverでは、Linux管理者は、次の方法でディレクトリーおよびそのファイルを安全に保護します。

1. ディレクトリーおよびそのファイルの所有者をmssql: chown -R mssql /mssql-

data-dirに変更する。

2. ディレクトリーおよびそのファイルのグループを mssql: chgrp -R mssql /mssql-

data-dirに変更する。

3. 所有者、グループ、その他の権限を次のように変更する。

chmod -R 750 mssql /mssql-data-dir

XtremIO X2アレイを使用してストレージを SQL Server コンテナーへ迅速に提供する方法を示すには、AdventureWorks

データベースを使用します。Microsoftによって作成された AdventureWorksは、AdventureWorks Cycles という架空の多

国籍製造企業をベースにしたサンプルのデータベースです。AdventureWorksデータベースは、データベースのバックアップをリス

トアするか、データファイルを追加してインストールできます。AdventureWorksデータベースでは OLTPアプリケーションをシミュ

レートし、SQL Serverの動作方法を習得するために使用できます。

この事例では、XtremIO X2アレイ上に AdventureWorksデータベースのコピーを配置します。統合されたコピーデータ管理

（iCDM）は、XtremIO X2上でデータのコピーをトラッキングし、重複排除を行います。したがって、XtremIO仮想コピーを使

用して AdventureWorksデータベースの関連するコピーを作成することにより、コピーで使用するアレイ上の領域がごくわずかに

なります。XtremIO仮想コピーを使用すると、1つの主要な AdventureWorksデータベースから複数のコピーを迅速に作成し

プロビジョニングできます。

ステップ 7：データベースアクセスの確認

事例 1を完了するために、開発者は次の図に示すように、Webブラウザーを使用して AdventureWorksデータベース内のデ

ータにアクセスすることによって、開発環境が動作していることを確認します。

図 5： Webブラウザーを使用した AdventureWorksデータへのアクセス

https://docs.microsoft.com/en-us/sql/samples/adventureworks-install-configure?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/samples/adventureworks-install-configure?view=sql-server-2017



ステップ 8：環境のクリーンアップ

事例 1のレビュー

Docker コンテナーは、一時用として設計されており、簡単に停止および破棄できます。また、新しいコンテナーを同じイメージから

構築することも、最小限の設定および構成で配置することもできます。Docker コンテナーの一時的な性質は、多くの開発者や他

のチームメンバーが短時間のみコンテナーを使用するような開発/テストのシナリオに最適です。この事例の最後の部分では、コンテナーを削除して、開発/テストの第 1 ラウンドからリソースをクリーンアップします。このク

リーンアップは、次の方法で迅速かつ簡単に行うことができます。

$ docker rm /SQLServer2019 $ docker rm /mssql-restapi

最初の事例における主なメリットは、SQL Server環境の従来のインストールと構成から Docker コンテナーの使用に至るトランス

フォーメーションでした。従来の構築プロセスは複雑であり、多くの時間と計画が必要となります。Docker コンテナーを使用すると、

従来の構築プロセスがセルフサービスのオンデマンド機能に変革され、開発者や他のユーザーがアプリケーションを迅速に導入でき

るようになります。

Docker コンテナーの使用には多くのメリットがあります。この最初の事例での主なメリットは、SQL Server コンテナーと永続スト

レージをわずか数分で実行できることです。この事例では、Docker コンテナー環境を設定しながら、サーバー環境の構成および Docker ライセンスにかかるコストへの影響に

ついて学習しました。また、事例 1の計画では、特定の開発/テスト環境の要件に最も適した Dockerレジストリーの場所とストレ

ージのプロビジョニングオプションを選択する重要性について実証されています。

サーバー環境の構成

Dell EMCではサーバーを幅広く選択できるため、お客様はビジネス要件に合わせてコンピューティングを構成できます。

PowerEdgeサーバー構成を幅広く選択できるということは、コアライセンスごとに Docker Enterprise Editionを最適化できると

いうことを意味しています。Docker ライセンスへの投資を最大限に活用する PowerEdgeサーバー環境の設計には、時間をかけ

ることをお勧めします。Docker環境を最大限に活用するための鍵は、CPUの利用効率を最大限に高める統合です。

Docker レジストリーの場所

Dockerレジストリーの場所を選択するときは、使いやすさとサポート、コンテナーのプロビジョニング速度、コンテナーのプロビジョ

ニング頻度を考慮してください。コンテナーのプロビジョニング速度と頻度に関する要件は、レジストリーを配置する場所を決定

するのに役立ちます。例えば、低速度および低頻度のプロビジョニングでは、クラウドベースのレジストリー方法が最適だと考え

られます。高速で頻度の高いプロビジョニングでは、LANを使用したローカルプライベートレジストリーが最適であると考えられ

ます。

ストレージのプロビジョニング

XtremIO X2アレイからのストレージのプロビジョニングは迅速かつ簡単ですが、これはストレージ管理者と開発者の間での調整

が必要となる手動のプロセスでもあります。この事例では、小規模な開発環境に適したストレージの手動プロビジョニングについて

実証しました。大規模な開発環境や環境サイズにかかわらず自動化に関心のあるお客様の場合は、以下の事例を使用してく

ださい。


19

事例 2：コンテナー化された開発/テスト環境の自動プロビジョニング

事例 2では、Kubernetesを XtremIO X2 CSI プラグインと組み合わせてストレージプロビジョニングを高速化する方法につ

いて説明します。

事例 1では、バインドマウントを使用して Dockerがホスト内のストレージを使用し、高速なパフォーマンスを提供しました。バイ

ンドマウントを使用する場合、すべてのサーバープロセッサーまたはユーザーがディレクトリーにアクセスできます。ただし、管理者は、

ディレクトリーとファイルの権限を使用して、所有者レベルおよびグループレベルでデータベースファイルを保護することによって、この

アクセスを管理できます。

ビジネスにおける意思決定の概要

次の表は、事例 1でコンテナー化された SQL Serverを実装するときに行った意思決定の概要を示しています。

表 4. 事例 1で行ったビジネスの意思決定の概要

選択肢意思決定説明

Docker Community EditionまたはEnterprise Edition

Enterprise Edition 認定されたイメージとビジネスサポートを提供

クラウドベースのプライベートレジストリーまたはローカルプライベートレジストリー

ローカルプライベートレジストリーコンテナーのプロビジョニングを最も迅速に提供するが、複雑性とサポート要件が増大する

XtremIO X2の手動または自動プロビジョニング

手動によるストレージプロビジョニングこの事例の限定された要件に対して適切

Dockerボリュームまたはバインドマウント

バインドマウントホストベースのハイパフォーマンスを提供


前述の事例では、XtremIO X2 アレイから永続的なストレージを使用したコンテナーの手動プロビジョニングについて説明しました。

次のステップでは、コンテナーとストレージのプロビジョニングを自動化して、ソフトウェア開発環境のプロビジョニングをさらに迅速化し

ます。数百または数千のコンテナーを管理する必要がある場合は、コンテナーのオーケストレーションが不可欠です。この事例では、

開発者は CSIプラグインをサービスとしてのプラットフォーム（PaaS）として使用し、Kubernetesで SQL Server コンテナーをデ

ータベースストレージとともにプロビジョニングします。

事例 2で、次の手順を実行します。

1. Kubernetes管理者は、Kubernetesのカスタムインストールを実行します。

2. ストレージ管理者は、Kubernetes管理者と協力して、XtremIO X2 CSIプラグインをインストールします。

3. 開発者は、Kubernetesを使用して SQL Server と REST API コンテナーをプロビジョニングします。

4. 開発者は、CSIプラグインを使用して AdventureWorksデータベースのコピーを作成します。



5. 開発者は、XtremIO仮想コピーを使用してデータベースのデータを変更し、データベースの状態を保護します。

6. テスターは過負荷テストを実施します。

7. 開発者は、変更された SQL Serverデータベースをリカバリーします。

8. テクニカルライターは、変更された SQLデータベースをプロビジョニングします。

9. 開発者はコンテナーを削除して、環境をクリーンアップします。

ステップ 1：Kubernetesのインストール

現在、多くの Kubernetesソリューションを利用できます。例えば、クラウドプロバイダーが提供するターンキー管理型

Kubernetes製品により、IT組織は、インストール不要のデータセンターを設置しないソリューションを実現できます。オンプレミス

のプライベートクラウドへの Kubernetesの実装は、制御性と柔軟性が向上しますが、インフラストラクチャとトレーニングに投資し

なければなりません。この事例では、基本的な Kubernetesのインストールを使用して、LAN上のコンテナーオーケストレーション

システムのパフォーマンスとコントロールを向上させる方法、ならびに構成をカスタマイズする機能について説明します。

注：Kubernetesの完全なインストール手順については、Kubernetesのドキュメントを参照してください。

Kubernetesは次のようにインストールします。

cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes- el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg exclude=kube* EOF # Set SELinux in permissive mode (effectively disabling it) setenforce 0 sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

yum install -y kubelet kubeadm kubectl -- disableexcludes=kubernetes

systemctl enable --now kubelet

ステップ 2：XtremIO X2 CSIプラグインのインストール

Kubernetes環境だけでなく、CSIプラグインの自動化作業も完了する必要があります。CSI プラグインは Kubernetesで定義された標準であり、Dell EMCおよびその他のユーザーが、コンテナーオーケストレーションシステムにブロックおよびファイルストレ

ージを公開するために使用します。CSIプラグインによって多くのコンテナーオーケストレーションシステム（Mesos、Docker

Swarm、Kubernetesなど）にわたるストレージ管理を統合します。

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/


21


Kubernetes向け XtremIO X2 CSIプラグインには、次のオーケストレーション機能が用意されています。

• ボリュームの動的なプロビジョニングと廃止

• ホストノードからのボリュームの接続と接続解除

• ホストノードからのボリュームのマウントとアンマウント

Kubernetes管理者は、ストレージ管理者と協力して、XtremIO X2 CSIプラグインを次の手順でダウンロード、変更、インスト

ールします。

注：詳細なインストール手順については、YouTubeの動画「Dell EMC XtremIO CSI Plugin Installation for Kubernetes」および以下の

ホワイトペーパーを参照してください。Dell EMC XtremIO X2 Container Storage Interface Plugin Integration with Kubernetes.

1. GitHubからプラグインをダウンロードします。

$ git clone https://github.com/dell/csi-xtremio-deploy.git

2. CSI.ini ファイルを変更して XtremIO X2アレイに接続します。

3. 最初のノードの実行時に、CSI プラグインをインストールします。

$ ./install -csi-plugin.sh -c

クラスター内の他のすべてのノードの場合

$ ./install -csi-plugin.sh -n

XtremIO X2ストレージアレイが Kubernetesで利用可能になります。次の図は、CSIプラグインがすべての Kubernetesワーカーノードで実行されている場合の kubectl get pods –all-namespaces 出力を示しています。

図 6： Kubernetesワーカーノードで実行されている XtremIO X2 CSIプラグイン

XtremIO X2アレイは、XtremIO X2 CSIプラグインによってプロビジョニングされたボリュームのインテリジェントな配置を使用しま

す。XtremIO X2ストレージ環境では、単一の管理インターフェイスである XtremIO Management Service（XMS）を使用

して、最大 4つのクラスターをサポートできます。デフォルトでは、CSIプラグインを使用して作成される永続ボリュームは、XMSが

決定した最も空き容量の多いクラスターに配置されます。XMSサーバーによるボリュームのインテリジェントな配置は、アレイが自

動的にロードバランシングされることを意味します。

または、クラスターIDを指定して、Kubernetes ストレージクラスのクラスターを明示的に選択することもできます。

https://www.youtube.com/watch?v=NXnFWmz4t_Y

https://www.youtube.com/watch?v=NXnFWmz4t_Y





次の図は、XMS インターフェイスのマルチクラスター構成を示しています。

図 7： XtremIO X2のマルチクラスター構成

XtremIO仮想コピーを使用するには、Kubernetes管理者がプロビジョニングを実行するスナップショットクラスを指定してから VolumeSnapshot YAML ファイルを作成する必要があります。このプロセスにより、開発者はデータベースのスナップショットを永続ボリュームに取得できます。

Docker管理者は、次のようにして基本的な VolumeSnapshot YAML ファイルを作成します。

apiVersion: storage.k8s.io/v1 kind: VolumeSnapshot metadata:

name: mssql-snapshot namespace: default

spec: snapshotClassName: csi-xtremio-xvc kind:

PersistentVolumeClaim

お客様の例として、次の YAML ファイルを GitHub にアップロードしました。

図 8：スナップショットの作成に使用される Kubernetes YAML ファイル

https://raw.githubusercontent.com/dellemcsql/PikesPeak/master/uc2/4-tm-copy-deployment.yaml


23


ステップ 3：SQL Serverおよび REST APIのプロビジョニングコンテナー

ステップ 4：データベースコピーのプロビジョニング

Kubernetesを使用して、開発者は SQL Server コンテナーと REST API コンテナーをポッド内で一緒にプロビジョニングします

（事例 1で説明したのと同じ中間層）。ポッドは、共有ネットワーキング、ストレージ、構成を使用した 1つ以上のコンテナーのグ

ループです。ポッドでは、次の図に示すように REST API を構成して SQL Serverに接続します。これにより 2つのアプリケーション

が緊密に統合します。ポッドを使用することの価値は、共有アプリケーションサービスの迅速なプロビジョニング、人的な構成エラーと

構成後の作業を最小限に抑える機能にあります。Kubernetesは、事例 1のコンテナーの手動プロビジョニングを使いやすいサー

ビスに変換します。

図 9： SQL Serverおよび REST API コンテナーのポッドのプロビジョニング

このステップでは、次の図に示すように、開発者が Kubernetes と XtremIO仮想コピーを使用して AdventureWorksデータ

ベースのコピーをプロビジョニングします。

図 10： Kubernetesを使用した AdventureWorksデータベースのプロビジョニングこのデータベースをプロビジョニングする迅速かつ簡単な方法によって、Docker コンテナーの柔軟性が増しリソース消費が軽減さ

れるため、追加の開発環境を容易に拡張できます。時間の節約と複雑性の軽減というビジネス上のメリットを同時に得られます。



ステップ 5：データベースデータの変更とデータベースの状態保護

AdventureWorksデータベースをプロビジョニングしたら、開発者はデータベースのデータを変更します。

次の図は、変更前のデータを示しています。

図 11：変更前のデータ

これは、開発者が表データの変更に使用する T-SQLです。

図 12：データの変更に使用される T-SQL


25


次の図は、変更後のデータを示しています。

図 13：更新されたデータ

変更した環境をテストチームにリリースする前に、開発者は XtremIO仮想コピーを使用してデータベースの状態を保護します。

XtremIO X2のデータ削減サービスにより、スナップショットが取得され、アレイに保存された後、一意のデータのみがデータベース

コピーに書き込まれます。また、スナップショット機能によって管理される一意のデータは圧縮されるため、容量の占有領域をさら

に削減できます。したがって、ほとんどの場合、データベースの XtremIO X2仮想コピーのスナップショットは、ストレージ領域をほと

んど必要とせず、作成と破棄の両方を迅速に行うことができます。

開発者は、次の XtremIO X2スクリーンをレビューして、AdventureWorksデータベースの XtremIO仮想コピーのスナップ

ショットが存在することを確認します。

図 14： XtremIOに表示されている AdventureWorksデータベースのスナップショット



ステップ 6：過負荷テストの実行と変更されたデータベースのリカバリー

この事例のシナリオでは、品質保証チームが最新バージョンの AdventureWorksデータベースアプリケーションに対して自動化

された過負荷テストを実施し、失敗します。したがって、開発者は、接続されたストレージを削除し、XtremIO仮想コピースナ

ップショットから AdventureWorksデータベースをリストアすることで、過負荷テストを実施する前の状態に戻します。

開発者は、次の YAML ファイルを使用してデータベースを以前のバージョンにリストアします。

apiVersion: v1 kind: PersistentVolumeClaim metadata:

name: mssql-restore spec: snapshotClassName: csi-xtremio-sc dataSource:

name: mssql-snapshot kind: VolumeSnapshot

apiGroup: snapshot.storage.k8s.io accessModes: ReadWriteOnce Resources:

Requests: Storage: 8Gi

次の図は、Kubernetesでのデータベースのリストアを示しています。

図 15：Kubernetesでのデータベースのリストア

データベースを迅速にリストアすることで、開発者の貴重な時間を節約できます。XtremIO 仮想コピー機能を使用して作

業を段階的に保存できる機能により、次を行うことでより反復型の開発が可能になります。

• 論理チェックポイントでの作業の保護

• 以前の XtremIO仮想コピースナップショットへの迅速なリカバリーによる過負荷テストの有効化

ステップ 7：テクニカルライターによる変更された SQLデータベースのプロビジョニング

XtremIO X2 CSIプラグインと Kubernetesを使用して組み合わせたコンテナーを使用することで、開発者の生産性を向上さ

せることができました。また、本番環境での作業とビジネスクリティカルなニーズに対応するためのストレージ管理者の貴重な時間

を節約することができました。同じメリットが他の役割にも同様に適用されます。例えば、テクニカルライターは、ソフトウェアを使

用して製品のアップデートや新機能を文書化する必要が多くあります。


27


次の図は、テクニカルライターが Kubernetesからアップデートされたポッドをプロビジョニングする方法を示しています。

図 16：テクニカルライターによる SQL Serverポッドのプロビジョニング

ステップ 8：環境のクリーンアップ

最後のステップでは、コンテナーとストレージの簡単な削除について説明します。ボリュームの操作を完了したユーザーは、保持ポ

リシーおよび削除ポリシーという 2つの XtremIO X2オプションを使用できます。

保持ポリシー

ユーザーは、保持ポリシーによってコンテナーをストレージから接続解除できます。ただし、ストレージが他のコンテナーに接続できる

ように永続ボリュームは保持しておきます。この機能を有効化するには（デフォルトの動作ではありません）、クラスター管理者は

次の例に示すように StorageClassを構成する必要があります。

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata:

name: csi-xtremio-qos-sc-high provisioner: csi-xtremio.dellemc.com

reclaimPolicy: Retain parameters qos_policy_id: “QoS_High”

ストレージは必要ないが、reclaimPolicyが［保持］に設定されるように

StorageClassを設定する場合、XtremIO X2 LUNを手動で削除できます。

削除ポリシー

削除ポリシーによってコンテナーをストレージから接続解除し、関連づけられたストレージ LUNを XtremIO X2アレイから削除

できます。削除ポリシーはデフォルトの動作であり、関連づけられたすべてのストレージを削除します。永続型ストレージを必要と

するデータベースやその他のアプリケーションについては、開発者やその他のユーザーがクラスター管理者と協力して、関連づけら

れたストレージが保持または削除されるか、変更を行う必要があるかどうかを把握する必要があります。この事例では、テクニカ

ルライターは AdventureWorksデータベースのコピーを保持する必要がないため、次の図に示すように、削除ポリシーを使用し

ます。

図 17：テクニカルライターによる Kubernetesでの SQL Server ポッドの削除


まとめ

事例 2のレビュー

CSIプラグイン：その他の Dell EMC オプション：

2つ目の事例では、Kubernetesを XtremIO X2プラグインと組み合わせることで、コンテナーとストレージのプロビジョニングおよび

削除を簡素化し、自動化しました。

この事例では、複雑なコマンドラインの使用やスクリプト作成からコンテナー管理を高速化するセルフサービスモデルに簡単に移

行できる方法について説明しました。ボトルネックを排除して開発者の生産性を向上させることができるセルフサービスモデルへの

移行は、今後 Docker コンテナー環境が拡大するにつれてますます重要になっていきます。

Kubernetesなどのコンテナーオーケストレーションシステムを使用することが、データベース開発者向けのコンテナー作業の次の

ステップとなります。自動化によって、コンテナー化されたアプリケーションの拡張が必要になります。この事例では、開発者が複雑

なスクリプト作成を回避し、Kubernetesアプリケーションを使用して開発者の目標を達成できるようにしました。CSIプラグイン

を Kubernetes と統合し、XtremIO X2アレイの機能を公開することにより、開発者は次のことが可能になります。

• XtremIO X2のゴールドマスターから AdventureWorksデータベースの XtremIO仮想コピースナップショットをプロビジョニングする

• XtremIO仮想コピースナップショットを作成して AdventureWorksデータベースでの作業を保護する

• AdventureWorksデータベースの保存されたコピーからデータベースをリストアする

• コンテナーと接続されたストレージの削除

この有効化で影響力のある部分は、従来は複数の役割（ストレージ管理者と協力し合う開発者およびその他のユーザーなど）

やより多くの時間を必要としていたステップです。CSI プラグインと Kubernetesにより、開発者や他のユーザーがより短時間でより

多くの作業を行うことができます。時間の節約とはプロジェクトの迅速な完了を意味します。これは開発者とビジネスの両方にとって

メリットがあります。全体として、2つ目の事例の主なメリットは、手動で管理されるコンテナー環境から、より多くのストレージ機能を

備えたオーケストレーションシステムへのトランスフォーメーションでした。

また、Dell EMCではお客様に Dell EMC VxFlex統合ラック向け CSI プラグインと VxFlexアプライアンスも用意して、

Kubernetesの幅広い機能を提供しています。VxFlex統合ラックおよび VxFlexアプライアンスは、PowerEdgeサーバーを使

用する VxFlex OSでサーバーベースの SANを作成します。ローカルサーバーとストレージリソースを組み合わせて、多様なパフ

ォーマンス階層を持つブロックストレージの仮想プールを作成します。詳細については、「VxRack FLEX and VxFlex Ready

Nodes for Kubernetes」を参照してください。VxFlex統合ラックおよび VxFlexアプライアンス向けの CSIプラグインは、Docker

Hubから入手できます。

Dell EMCの CSIプラグインに関する詳細については、「Dell EMC Storage Automation and Developer

Resources」を参照してください。

まとめ

イノベーションがトランスフォーメーションを推進します。Docker コンテナーと Kubernetesでは、迅速なアプリケーション導入サービ

スへの移行が主なメリットです。Microsoftやその他多くの企業がコンテナーを採用し、わずか数日で統合し、数秒でインスタンス

化することができる SQL Serverなどのアプリケーションのイメージを提供しています。インストールやその他の反復タスクは、開発

者が

https://www.dellemc.com/ja-jp/collaterals/unauth/data-sheets/products/ready-solutions/vxflex_kubernetes_solution_brief.pdf

https://www.dellemc.com/ja-jp/collaterals/unauth/data-sheets/products/ready-solutions/vxflex_kubernetes_solution_brief.pdf

https://hub.docker.com/r/dellemc/csi-vxflexos

https://hub.docker.com/r/dellemc/csi-vxflexos

https://www.dellemc.com/en-us/storage/storage-automation-and-developer-resources/index.htm




29

今後について

データベースですぐに作業できるパッケージ化されたアプリケーションに置き換えられます。永続的なストレージの迅速なプロビジョニン

グと組み合わせた使いやすい Docker と Kubernetesによって、待機時間を解消し、開発者の考える時間を減らして開発を変革

します。

事例 1では Docker コンテナーへの移行が開発者にとってメリットがある一方、ストレージのプロビジョニングと接続を手動で実行

することから、アプリケーション開発の全体的な速度を遅くしていました。手動でストレージをプロビジョニングする場合の課題は、多

様性と速度です。IT組織がアプリケーションイメージを増やしていくにしたがって、多様性が管理とサポートをより複雑にしていきま

す。速度は、アプリケーションのプロビジョニング頻度を表しますが、選択肢の増加に伴って増える傾向があります。速度の向上は

成長指標でもありますが、同時に IT組織の自動化への対応にプレッシャーを与えることにもなります。

2つ目のトランスフォーメーションは、Kubernetesのオーケストレーションシステムと XtremIO X2 CSI プラグインの追加でした。

Kubernetesによって、コンテナーと永続ストレージのプロビジョニングを簡素化する優れたユーザーインターフェイスが導入されま

した。テストでは、Kubernetesに XtremIO X2 CSI プラグインを加えることによってセルフサービスのオンデマンド機能が有効に

なることがわかりました。この機能により、開発者は、ポイントアンドクリックのシンプルな操作で、永続ストレージでコンテナー化さ

れたアプリケーションをプロビジョニングできるようになり、貴重なストレージ管理者の時間を解放してビジネスクリティカルなタスクに

専念することができるようになりました。

XtremIO X2 CSIプラグインによって強化された Kubernetesは、コンテナー化されたアプリケーションにオールフラッシュ XtremIO X2ボ

リュームを接続して管理する機能を提供しました。開発者は使い慣れた Kubernetesインターフェイスを使用してAdventureWorks

データベースのコピーを作成し、SQL Serverコンテナーに接続しました。データベースを変更した後、開発者は XtremIO仮想コピーを

使用してデータベースのコピーを保存することで、進行状況を保護することができました。

Dockerおよび Kubernetes インフラストラクチャに移行することで、SQL Serverをより迅速かつ一貫した方法でパッケージ化し

導入することができます。Microsoft と、Dockerおよび Kubernetes をサポートするオープンソースコミュニティーにより、多くの基

本作業はすでに完了しています。手動またはスクリプト形式のインストール手順は必要はありません。カスタマイズのみ行ってくださ

い。Dell EMCは、XtremIO X2エンタープライズストレージテクノロジーと、アプリケーションの配信をストリーミングする CSI プラグ

インを使用してストレージの価値を高めています。このホワイトペーパーの目的は、アプリケーション開発のトランスフォーメーションを

促進して、お客様がこれらすべてのメリットを享受できるようにすることです。Dell EMCでは、コンテナー化されたアプリケーションを

最適化するインフラストラクチャを提供する方法について説明し、実際にこのインフラストラクチャを提供します。

今後について

SQL Server 2019の一般公開により、常時オンの本番環境グループといった別の本番環境事例が使用できるようになる予定で

す。また一方で、Always On Listener構成が主要なアプリケーションのロードバランサになります。ローリングアップグレードが本番

環境の標準となり、SQL Serverのパッチとアップデートプロセスが大幅に簡素化されます。

また、近い将来、XtremIO仮想コピーは、現在仮想マシンのノードで実行されているように、より大規模な常時オンレプリカの基

盤となる予定です。


付録 A：ソリューションのアーキテクチャとコンポーネントの仕様


アーキテクチャ図

サーバーレイヤー

次の図に、設計アーキテクチャを示します。

図 18：ソリューションアーキテクチャ

サーバーレイヤーは、3台の PowerEdge R740サーバーで構成されています。PowerEdge R740は 2U ラックサーバーで、

以下をサポートします。

• インテル Xeonスケーラブルプロセッサー x 2

• 1,536 GB メモリー（最大）をサポートする 24個の DIMMスロット

• ACまたは DC PSU（電源装置ユニット）x 2

• SAS、SATA、ニアライン SASのハードドライブまたは SSD x 16

3 ノード Kubernetes クラスターとして 3つのベアメタルサーバーを構成しています。各ノードは Red Hat Enterprise Linux 7.6

をホストしています。


31


以下の表に、PowerEdge R740の構成の詳細を示します。R740サーバーのリソース上限が大幅に増加していますが、この構

成では、開発/テスト環境で使用するコンテナー化された SQL Server インスタンスのメリットを示すための機能設計をサポートし

ていれば十分です。

表 5： PowerEdge R740 サーバーの構成

コンポーネント詳細

シャーシ 2台の CPU構成

メモリー DDR4デュアルランク 32 GB @ 2,400 MHz x 12

プロセッサインテル Xeon Silver 4110 CPU @ 2.10 GHz x 2、8 コア

ホストバスアダプター（Host bus adapters）

Emulex LightPulse LPe31002-M6-D 2ポート 16 Gb ファイバーチャネル x 2

rNDC BRCM GbE 4P 5720-t rNDC

アドオン NIC インテル 10 GbE 2P X710

電源装置 Dell 2,260 W x 2

RAID コントローラー Dell H740P

iDRAC iDRAC9 Enterprise

物理ディスク • 2 x 900 GB SSD

• 4 x 1.92 TB HDD

ネットワーク層

ネットワーク層は、次のスイッチで構成されています。

• 10 GbEネットワークスイッチ x 2：Kubernetes ノード上の 10 Gbポート x 2に接続し、ネットワークトラフィックを経路指定する

• 16 Gb/秒ファイバーチャネル（FC）ファブリックスイッチ x 2：R740サーバーと XtremIO X2ストレージアレイ間でSAN トラフィックを経路指定する

次の図は、HBA（ホストバスアダプター）と FCスイッチ間の推奨される FC接続を示しています。また、FCスイッチと XtremIO

X2ストレージアレイの間の接続についても示しています。図に示すように、各サーバーの HBAポートは、2つの別々の FCスイッ

チに接続され、各 XtremIO X2アレイコントローラー上の 2個のフロントエンドポートは、これらの同じ FCスイッチに接続されます。



図 19： FC ファブリック接続の設計

ストレージレイヤー

XtremIO X2ストレージアレイを FC SANストレージとして使用し、CSIプラグインを使用して Kubernetes上の SQL

Server 2019をテストしました。

ストレージレイヤーは、次のコンポーネントで構成されています。

• X-Brickモジュール x 2、72 x 2 TB フラッシュベース SAS SSDを搭載した XtremIO X2 クラスター

• 各 X-Brickモジュールに 2台のコントローラーと 1台の DAE（ディスクアレイエンクロージャ）

• 16 Gb/秒フロントエンド FCポート x 4

• 2つの X-Brick接続用 InfiniBandスイッチ x 2


33

冗長性

マルチパス機能

ソフトウェアコンポーネント

LANおよび SANの設計では、単一障害点が存在しないようにするため、冗長性のあるコンポーネントと接続を各レベルで備えて

います。この設計により、アプリケーションサーバーがデータベースサーバーにアクセスできるようになり、コンポーネントに障害が発生

した場合でも、データベースサーバーがストレージアレイに到達できるようになります。この設計により、1つ以上の NICまたは

HBAポート、1つの LANまたは FCスイッチ、1つ以上の XtremIO X2 フロントエンドポート、1つの XtremIO X2 X-Brick コン

トローラーで障害が発生した場合でも保護されます。

XtremIO X2アレイでは、ネイティブマルチパステクノロジーをサポートしています。マルチパス機能は、PowerEdgeサーバーを

XtremIO X2ストレージに接続する冗長ハードウェアパスにおけるデータ送信の効率性を高めます。メリットとしては、ラウンドロビン

を使用して I/Oを交代させることにより、ハードウェアパスの使用を最適化し、データの分散均等性を高められる点があります。別

のメリットとして、ストレージパスのコンポーネントに障害が発生した場合に、NMPは接続をリセットし、代替パスを使用して I/Oを

渡す点も挙げられます。

次の表で、ソリューションソフトウェアコンポーネントの詳細について説明します。

表 6：ソフトウェアコンポーネント

コンポーネント詳細

Red Hat Enterprise Linux Server 7.6（3.10.0-957.el7.x86_64）（Maipo）

Docker Enterprise Edition 18.09.7

Kubernetes 1.15.0

Flannel（ポッドネットワークオーケストレーション） 0.11.0-amd64

MetalLB（ロードバランサ） 0.7.3

Microsoft SQL Server 2019 CTP 3.0


付録 B：コンテナーリソースの構成

付録 B：コンテナーリソースの構成

ここでは、コンテナーリソースを構成するための補足情報を提供します。前述のとおり、デフォルトでは、ホストの CPUサイクルに対する Docker コンテナーアクセスは無制限です。ホストのカーネルスケジューラによって制限されている場合を除き、ホストメモリー

へのアクセスも無制限です。ここでは、コンテナーの CPU リソースを制限し、コンテナーにメモリーを割り当てることによって、これらの

デフォルトの動作を上書きする方法について説明します。

CPU

メモリー

コンテナーあたりの CPU リソースを制限するためのさまざまな方法については、コンテナーを開始するときに、−cpus フラグを指定するのが最も簡単な方法の 1つです。フラグによって、CPU リソースの構成が CFS（Completely Fair Scheduler）に送信されます。これは Linux カーネルの CPUスケジューラで、通常の Linuxプロセスで使用されます。−cpus フラグは、コンテナーが使用できる CPU リソースの最大数を指定します。次の例では−cpus=“2”を使用して、コンテナーをサーバー上で最大 2 コアに制限します。

$ docker run –cpus=“2” --name sqlservername -e “ACCEPT_EULA” -e “MSSQL_SA_PASSWORD=password” -v volumename:/var/opt/mssql-data-dir -p 1433:1433 -d localhost:5000/sql2019

データベースなどのプロセッサー集約型アプリケーションの場合、CPU 設定で SLA の管理と統合の強化を支援します。

コンテナーには、次の 2つの方法のいずれかでメモリーを割り当てることができます。–mまたは

−−memory フラグ。コンテナーで使用できるメモリーの最大量を指定します。例えば、SQL Server イメージに必要な最小メモリー量は、2 GB RAMです。データベースはより多くのメモリーを活用するため、次のコマンドに示すように 16 GBを使用しています。

$ docker run –cpus=”2” –-memory=16g --name sqlservername -e “ACCEPT_EULA” -e “MSSQL_SA_PASSWORD=password” -v volumename:/var/opt/mssql-data-dir -p 1433:1433 -d localhost:5000/sql2019

メモリーを構成する 2つ目の方法は、–memory-reservation フラグを使用することです。このフラグを使用すると、次のコマンドに示すように、–-memory構成よりも小さいソフトリミットを指定できます。Dockerがサーバー上でメモリーの競合を検出した場合、–memory-reservation フラグの設定でコンテナーの最小メモリー量が指定されます。

$ docker run –cpus=”2” –-memory=16g –memory-reservation=4g --name sqlservername -e “ACCEPT_EULA” -e “MSSQL_SA_PASSWORD=password” -v volumename:/var/opt/mssql-data-dir -p 1433:1433 -d localhost:5000/sql2019

–-memoryおよび–memory-reservation フラグを使用することで、ハードメモリーの制限を適用して、サーバーでのメモリー不足の発生を防ぐことができます。

https://docs.docker.com/config/containers/resource_constraints/

Documents

Linux 上の SQL Server 2019 コンテナー - Dell Technologies...Linux 上の SQL Server 2019コンテナー Dell EMC インフラストラクチャを使用したソフトウェア開発の事例