Amazon Web Services ブログ

Amazon Linux 2 AMI および Ubuntu AMI での SQL Server 2017 の設定方法

AWS で Microsoft SQL Server をデプロイするときは、アプリケーションのパフォーマンス、可用性、信頼性、およびコストをどのように最適化するかに関する数多くの選択肢があります。Amazon では、使用方法を最適化し、コストを削減するために、複数の SQL Server バージョン、幅広いコンピューティングオプション、および多数のライセンスオプションをご用意しています。従量制料金モデルを選択して AWS のライセンスが包含されたオプションを使用する、または Amazon EC2 で独自のライセンスを使用する (BYOL) ことができます。

EC2 インスタンスで利用できる SQL Server 2017 には、Amazon EC2 で実行される Microsoft Windows または Linux オペレーティングシステムのどちらかに SQL Server ベースのアプリケーションをデプロイする柔軟性があります。AWS は本日、ライセンスが包含された Amazon Machine Image (AMI) を提供することによる、Amazon Linux 2 および Ubuntu での Microsoft SQL Server のサポートを発表しました。このリリースでは、ライセンスが包含された AMI を EC2 コンソールから直接使用して、Amazon Linux 2 LTS Candidate と Ubuntu 16.04 (HVM) の各インスタンスに SQL Server 2017 をオンデマンドで起動できます。AMI は、SQL Server Web Edition、SQL Server Express Edition、SQL Server Standard Edition、および SQL Server Enterprise Edition の 4 つのエディションすべてで利用できます。

このブログ記事では、従来の Windows ベースの設定と、新しい Linux SQL Server インストールにおける管理の違いについて説明します。また、Amazon EC2 の Linux AMI で実行される SQL Server の設定手順も詳しく説明します。

この記事は、このブログ記事の一環としてインストールする SQL Server インスタンスに接続するため、VPC 内にワークステーションが設定されていることを前提としてます。AWS は、そのワークステーションから SQL Server Management Studio (SSMS) を使用することを推奨します。SSMS の各ビット版はこちらのサイトからダウンロードできます。

Linux と Windows で SQL Server を設定する場合の違い

Linux で実行されているときの SQL Server の設定は、Windows で実行されている SQL Server の設定とは異なります。従来の Windows 環境では、SQL Server サービス、TCP ポート、スタートアップパラメーター、またはその他すべてのインスタンスレベルの設定項目への変更を管理するために SQL Server Configuration Manager を使用します。

Linux ベースの SQL Server ワークロードについては、Microsoft が mssql-conf という名前の設定スクリプトを利用できるようにしています。mssql-conf スクリプトは、デフォルトのデータファイルとログファイルの場所、TCP ポートなどにパラメーターを設定するために使用されます。

では、設定手順を開始しましょう。

始める前に

開始する前に行うセットアップがいくつかあります。

  1. SQL Server を実行する Linux EC2 インスタンスに正常に接続したら、root ユーザーアカウントを使用してコマンドを実行できるように、以下のコマンドを実行してください。
    sudo su

    Linux インスタンスに追加したボリュームとデバイスを確認するには、lsblk を実行して、起動中にアタッチしたすべての Amazon EBS ボリュームのリストを表示します。

    すべての Amazon EBS ボリュームのリストを取得するための lsblk コマンドのスクリーンショット

  2. この AMI には SQL Server 2017 が含まれているため、SQL Server インスタンスの SA パスワードをリセットします。これを行うには、まず以下のコマンドを使って SQL Server インスタンスを停止します。
    sudo systemctl stop mssql-server

    次に、以下の mssql-conf スクリプトを実行して SA パスワードをリセットします。

    sudo /opt/mssql/bin/mssql-conf set-sa-password

1.ターゲットディレクトリを作成してデフォルトディレクトリを変更する

ベストプラクティスとして、所定の SQL Server インスタンスのログファイルからデータファイルを隔離することが推奨されます。デフォルトディレクトリの場所を変更する前に、まず新しいデータベースのデータファイルとログファイル用のターゲットディレクトリを作成します。

以下の手順は、/SQLServerData という名前の新しいディレクトリを作成します。これを行う前に、ファイルシステムをフォーマットし、ディレクトリを作成して、そのディレクトリをデバイス (ボリューム) にマウントする必要があります。

  1. 以下のコマンドを使用して、ext4 ファイルシステムを使用するために、自分で選択したボリュームをフォーマットします。
    sudo mkfs –t ext4 /dev/devicename

    例: sudo mkfs -t ext4 /dev/xvdc

  2. ディレクトリを作成します。この例は、/SQLServerData を使用します。
    sudo mkdir /SQLServerData
  3. 以下のコマンドを使用して、ボリュームを /SQLServerData ディレクトリにマウントします (この例には /dev/xvdc ボリュームを使用します)。
    sudo mount /dev/xvdc /SQLServerData
  4. ディレクトリの所有者とグループを mssql ユーザーに変更します。
    sudo chown mssql /SQLServerData
    sudo chgrp mssql /SQLServerData

    これらの手順を完了したところで、set コマンドを使用してデフォルトのデータディレクトリを変更することができます。filelocation.defaultdatadirfilelocation.defaultlogdir の設定は、新しいデータベースとログファイルが作成される場所を変更します。デフォルトで、この場所は /var/opt/mssql/data になっています。

  5. この設定を変更するには、以下の手順に従ってください (この例は、デフォルトのデータディレクトリとして /SQLServerData を使用します)。
    sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /SQLServerData

    前のステップが完了したら、新しい設定を適用するために SQL Server を再起動する必要があります。再起動する前に、データベースログファイル専用の別のボリュームもディレクトリにマウントしましょう。

  6. 以下のコマンドを実行して、インスタンスにアタッチしたディスクをリストします。
    lsblk

    上記のスクリーンショットから、/dev/xvdc には /SQLServerData マウントポイントがあることがわかります。この手順には同じようなマウントポイントが含まれていますが、これはデフォルトのログディレクトリ用のものです。

  7. ext4 ファイルシステムを使用するようにボリュームをフォーマットします (この例には xvdd ボリュームが使用されています)。
    sudo mkfs -t ext4 /dev/xvdd
  8. 新しい ext4 ボリュームをマウントするために、自分で選択したディレクトリを作成します (この例では、新しいディレクトリの名前に /SQLServerLog を使用します)。
    sudo mkdir /SQLServerLog

2.ボリュームをマウントしてデフォルトのログディレクトリを設定する

ディレクトリが作成されたところで、自分で選択したボリュームを新しいディレクトリにマウントします。

  1. ボリュームは、以下のコマンドを使ってマウントします (この例は /dev/xvdd ボリュームを使用します)。
    sudo mount /dev/xvdd /SQLServerLog
  2. ボリュームがマウントされたら、ディレクトリの所有者とグループを mssql ユーザーに変更します。
    sudo chown mssql /SQLServerLog
    sudo chgrp mssql /SQLServerLog

    ディレクトリが作成され、ボリュームがマウントされたので、現在 2 つの場所があるはずです。ひとつのディレクトリはデータベースのデータファイル用で、もうひとつはデータベースのログファイル用です。

  3. 現在のマウントポイントを確認するためにブロックデバイスをリストするには、lsblk コマンドを実行します。lsblk コマンド出力のスクリーンショット上記のスクリーンショットから、現在データベースのデータファイルとログファイル用に 2 つの個別のマウントポイントがあることがわかります。
  4. ログファイル用のディレクトリができたので、mssql-conf スクリプトを使って SQL Server インスタンスにデフォルトのログディレクトリを設定できます。これは、以下のコマンドを実行して行ってください。
    sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /SQLServerLog

    デフォルトのディレクトリの設定後は、このメッセージが表示されます。

  5. デフォルトのログディレクトリを設定すると、mssql-server を再起動するプロンプトが表示されます。これは、以下のコマンドを実行して行ってください。
    sudo systemctl restart mssql-server

3.デフォルトのバックアップ場所を変更する

デフォルトのバックアップ場所を変更するには、ファイルシステムを作成するために実行したものと同じ手順に従ってください。これらの手順は、ディレクトリの作成、ディレクトリへのボリュームのマウント、マウントポイントの所有権とグループの変更、デフォルトの場所の変更、および mssql-server サービスの再起動です。

  1. このコマンドを実行してデフォルトのバックアップディレクトリを変更します。
    sudo /opt/mssql/bin/mssql-conf set defaultbackupdir /YourNewBackupDirectory
  2. 3 つのデフォルトディレクトリをすべて設定したら、lsblk を実行して、どのデバイスとボリュームがマウントポイントに関連付けられているかを表示します。結果は、以下のようになるはずです。
  3. SSMS を開き、サーバーのコンテキスト (右クリック) メニューを開いて、[プロパティ] を選択します。
  4. [データベースの設定] タブを選択して、新しいデータベースのデフォルトの場所がどこになっているかを確認します。このタブは、データベースのデータファイル、ログファイル、およびバックアップファイルを分離する目的のために作成してマウントしたディレクトリを表示し、参照しているはずです。

4.必要に応じてメモリ消費を設定する

Linux インスタンスで SQL Server が消費できるメモリの量を設定することがアプリケーションにとって重要である場合は、mssql-conf スクリプトで memory.memorylimitmb 設定を使用することによって設定できます。

  1. 以下のコマンドを実行して、mssql-conf スクリプトで memory.memorylimitmb 設定を使用します。メモリ上限は 3328 MB にします。
    sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 3328
  2. 以下のコマンドを実行してサービスを再起動します。これは上記の設定変更に従う必要があります。
    sudo systemctl restart mssql-server

5.トレースフラグを有効化または無効化する

SQL Server サービスのスタートアップのためにトレースフラグを有効化または無効化することもできます。トレースフラグは 1222 に設定することが推奨されます。これは、デッドロックの診断に役立ちます。

  1. トレースフラグを有効化または無効化するには、以下のコマンドを使用します。
    • トレースフラグを有効化するには、以下のコマンドを実行します。
      sudo /opt/mssql/bin/mssql-conf traceflag 1222 on
    • トレースフラグを無効化するには、以下のコマンドを実行します。
      sudo /opt/mssql/bin/mssql-conf traceflag 1222 off

    上記のコマンドを使ってトレースフラグが設定されると、SQL Server サービスが再起動されるたびに包含されるように (mssql-server.service 用のスタートアップパラメーター)、グローバルで設定されます。

  2. 以下のコマンドを実行して mssql-server.service を再起動します。
    sudo systemctl restart mssql-server

6.TempDB のログファイルとデータファイルを隔離する

予期しないデータベースの拡大がオペレーティングシステムに影響を及ぼさないようにするため、異なるディレクトリと異なるボリュームに TempDB データベースのログファイルとデータファイルを隔離することをお勧めします。これを行うには、これらの手順に従ってください。

  1. ext4 ファイルシステムを使用するようにボリュームをフォーマットします (この例には xvdd ボリュームが使用されています)。
    sudo mkfs -t ext4 /dev/xvde
  2. 新しい ext4 ボリュームをマウントするために、自分で選択したディレクトリを作成します。この例は、新しいディレクトリの名前に /SQLServerTempDB を使用します。
    sudo mkdir /SQLServerTempDB
  3. 以下のコマンドを使って、自分で選択したボリュームを新しいディレクトリにマウントします (この例は /dev/xvdd ボリュームを使用します)。
    sudo mount /dev/xvdd /SQLServerTempDB
  4. ディレクトリの所有者とグループを mssql ユーザーに変更します。
    sudo chown mssql /SQLServerTempDB
    sudo chgrp mssql /SQLServerTempDB
  5. TempDB ファイルを新しい場所に移動させるには、以下にあるように、通常 TempDB ファイルがある Windows 上の SQL Server で行うとおりに移動させてください。SSMS クエリウィンドウを開くには、SSMS を開き、サーバーのコンテキスト (右クリック) メニューを開いてから、[新しいクエリ] を選択します。
  6. 以下のコマンドを実行して、現在 TempDB のデータファイルとログファイルが格納されている場所をクエリします。上記のスクリーンショットからわかるように、TempDB のデータファイルとログファイルが同じディレクトリに格納されています。
  7. ALTER DATABASE を使用して各ファイルの場所を変更します。
  8. 以下のコマンドを実行して SQL Server のインスタンスを停止し、再開します。
    sudo systemctl restart mssql-server
  9. 変更を確認するには、ステップ 4 で実行したものと同じクエリを実行します。以下のスクリーンショットから、/dev/xvdd にマウントされた /SQLServerTempDB ディレクトリに TempDB が正常に移動されていることがわかります。
  10. 10.マウントがシステムの再起動後も存続することを確実にするには、デバイスのエントリを /etc/fstab ファイルに追加します。デバイスの名前、使用済みの容量などに関するすべてのマウントポイント情報のリストを取得するには、「df」コマンドを実行できます。/etc/fstab にはシステムの現在のデバイス名 (/dev/sda1、/dev/xvda1 など) を使用できますが、その代わりにデバイスの 128 ビットの汎用一意識別子 (UUID) を使用することをお勧めします。
    Run 'file –s /devicename' command to get the UUID

    fstab ファイルの最上部に新しい行を追加し、デバイスに固有の UUID 貼り付け、マウントポイントを追加して (この例では /SQLServerData を使用)、ファイルシステムのタイプ (この例では ext4) とマウントオプションを入力します (詳細については、https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html にあるステップ 7c を参照してください)。

    再起動後も存続させたいすべてのマウントポイントとデバイスに上記の手順を繰り返します。デバイスが /etc/fstab ファイルに正常に保存されたことを確認するには、「cat /etc/fstab」を実行します。

これで、管理しやすくするために実装されたベストプラクティスを使って Linux AMI で SQL Server 2017 を使用する準備が整いました。


著者について

Bini Berhe はアマゾン ウェブ サービスのソリューションアーキテクトです。