Exadata Cloud Serviceインスタンスの手動更新

このトピックでは、Exadata Cloud Serviceインスタンスのコンピュート・サーバー・ノード(クラウドVMクラスタの場合、これらは仮想マシンと呼ばれます)でオペレーティング・システムおよびツールを更新する方法について説明します。更新を開始する前に、すべての情報を慎重に確認してください。

Exadata Cloud ServiceおよびExadata Cloud@Customerシステムのクラウド・ツールに関する問題の診断の詳細は、DBAASツール: dbaascliを使用したクラウド・ツール・ログの収集およびクラウド・ツールのヘルス・チェックの実行を参照してください。

Exadata Cloud VMクラスタOSの手動更新

patchmgrツールを使用して、Exadataコンピュート・ノードのオペレーティング・システムを更新します。このユーティリティでは、再起動前、再起動時および再起動後のステップの実行など、1つ以上のコンピュート・ノードの更新全体がリモートで管理されます。ユーティリティは、Exadataコンピュート・ノードまたはOracle Linuxを実行しているExadata以外のサーバーから実行できます。ユーティリティを実行するサーバーは、「駆動システム」と呼ばれます。駆動システムを使用してそれ自体を更新することはできません。したがって、更新しているシステム上で駆動システムがExadataコンピュート・ノードの1つである場合、別の駆動システム上で別途操作を実行してそのサーバーを更新する必要があります。

次の2つのシナリオは、更新を実行する一般的な方法を示しています:

シナリオ1: Exadata以外の駆動システム

Exadataシステムの更新を実行する最も簡単な方法は、別のOracle Linuxサーバーを使用して、システムのすべてのExadataコンピュート・ノードを更新することです。

シナリオ2: Exadataノード駆動システム

1つのExadataコンピュート・ノードを使用して、システムの残りのコンピュート・ノードの更新を駆動し、更新されたノードのいずれかを使用して元のExadataドライバ・ノードで更新を駆動できます。

例: node1、node2、node3、node4という4つのコンピュート・ノードがあるハーフ・ラックExadataシステムを更新しています。まず、node1を使用してnode2、node3およびnode4の更新を駆動します。その後、node2を使用してnode1の更新を実行します。

駆動システムは、ユーティリティによって更新される各コンピュート・ノードに対するルート・ユーザーSSHアクセスを必要とします。

OSの更新の準備

注意

Exadata Cloud ServiceインスタンスにはNetworkManagerをインストールしないでください。このパッケージをインストールしてシステムを再起動すると、システムへの重大なアクセス消失が発生します。

  • 更新を開始する前に、Exadata Cloud Serviceソフトウェア・バージョン(ドキュメントID 2333222.1)を確認して、使用する最新のソフトウェア・バージョンとターゲット・バージョンを判断してください。
  • 更新プロセスの一部のステップでは、YUMリポジトリを指定する必要があります。YUMリポジトリのURLを次に示します:

    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    リージョン識別子は、Oracle Cloud Infrastructureリージョンの識別に使用されるテキスト文字列です(例: us-phoenix-1)。リージョン識別子の完全なリストは、リージョンで確認できます。

    次のcurlコマンドを実行して、Exadata Cloud Serviceインスタンス・リージョンのYUMリポジトリの最新バージョンを確認できます:

    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/index.html |egrep "18.1."

    次の例では、米国西部(フェニックス)リージョンのYUMリポジトリの最新バージョンが返されます:

    curl -s -X GET http://yum-us-phoenix-1.oracle.com/repo/EngineeredSystems/exadata/dbserver/index.html |egrep "18.1."
    <a href="18.1.4.0.0/">18.1.4.0.0/</a> 01-Mar-2018 03:36 -
  • OS更新を適用するには、YUMリポジトリへのアクセスを許可するようにシステムのVCNを構成する必要があります。詳細は、オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセスを参照してください。
Exadata Cloud Serviceインスタンスのすべてのコンピュート・ノードでOSを更新するには

この例の手順では、次のことが想定されています:

  • システムには、node1およびnode2という2つのコンピュート・ノードがあります。
  • ターゲット・バージョンは18.1.4.0.0.180125.3です。
  • 2つの各ノードは、他方のノードで更新するための駆動システムとして使用されます。
  1. 環境詳細を収集します。

    1. rootとしてnode1SSHで接続し、次のコマンドを実行してExadataのバージョンを確認します:

      [root@node1]# imageinfo -ver
      12.2.1.1.4.171128
    2. グリッド・ユーザーに切り替えて、クラスタ内のすべてのコンピュートを識別します。

      [root@node1]# su - grid
      [grid@node1]$ olsnodes
      node1
      node1
  2. 駆動システムを構成します。

    1. node1のrootユーザーに切り替えて、root sshキー・ペア(id_rsaおよびid_rsa.pub)がすでに存在するかどうかを確認します。存在しない場合は生成します。

      [root@node1 .ssh]#  ls /root/.ssh/id_rsa*
      ls: cannot access /root/.ssh/id_rsa*: No such file or directory
      [root@node1 .ssh]# ssh-keygen -t rsa
      Generating public/private rsa key pair.
      Enter file in which to save the key (/root/.ssh/id_rsa):
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      Your identification has been saved in /root/.ssh/id_rsa.
      Your public key has been saved in /root/.ssh/id_rsa.pub.
      The key fingerprint is:
      93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.fraad1client.exadataclientne.oraclevcn.com
      The key's randomart image is:
      +--[ RSA 2048]----+
      |o..     + .      |
      |o.     o *       |
      |E     . o o      |
      | . .     =       |
      |  o .   S =      |
      |   +     = .     |
      |    +   o o      |
      |   . .   + .     |
      |      ...        |
      +-----------------+
    2. 公開キーをターゲット・ノードに配布して、このステップを確認します。この例では、ターゲット・ノードはnode2のみです。

      [root@node1 .ssh]# scp -i ~opc/.ssh/id_rsa ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
      id_rsa.pub
      
      [root@node2 ~]# ls -al /tmp/id_rsa.node1.pub
      -rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
      [root@node2 ~]# date
      Wed Feb 28 03:33:45 UTC 2018
      
    3. ターゲット・ノード(この例ではnode2)で、ルートのauthorized_keysファイルにnode1のルート公開キーを追加します。

      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
      
    4. dbserver.patch.zipp21634633_12*_Linux-x86-64.zipとして駆動システム(この例ではnode1)にダウンロードし、解凍します。この.zip内のファイルの詳細は、dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Databaseサーバー・ソフトウェアの更新(ドキュメントID 1553103.1)を参照してください。

      [root@node1 patch]# mkdir /root/patch
      [root@node1 patch]# cd /root/patch
      [root@node1 patch]# unzip p21634633_181400_Linux-x86-64.zip
      Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
         creating: dbserver_patch_5.180228.2/ibdiagtools/
        inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
        inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
        inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
       extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
        inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
        inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
         creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
        inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
         creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
        inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
        inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
        inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
        inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
        inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
        inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
         creating: dbserver_patch_5.180228.2/linux.db.rpms/
        inflating: dbserver_patch_5.180228.2/md5sum_files.lst
        inflating: dbserver_patch_5.180228.2/patchmgr
        inflating: dbserver_patch_5.180228.2/xcp
        inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
        inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
        inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
        inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
        inflating: dbserver_patch_5.180228.2/exadata.img.env
        inflating: dbserver_patch_5.180228.2/README.txt
        inflating: dbserver_patch_5.180228.2/exadataLogger.pm
        inflating: dbserver_patch_5.180228.2/patch_bug_26678971
        inflating: dbserver_patch_5.180228.2/dcli
        inflating: dbserver_patch_5.180228.2/patchReport.py
       extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
         creating: dbserver_patch_5.180228.2/plugins/
        inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
        inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
        inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
        inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
        inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
        inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
        inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
        inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
        inflating: dbserver_patch_5.180228.2/patchmgr_functions
        inflating: dbserver_patch_5.180228.2/exadata.img.hw
        inflating: dbserver_patch_5.180228.2/libxcp.so.1
        inflating: dbserver_patch_5.180228.2/imageLogger
        inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
        inflating: dbserver_patch_5.180228.2/fwverify
      
    5. 更新するコンピュート・ノードのリストを含むdbs_groupファイルを作成します。ステップ1でolsnodesコマンドを実行した後にリストされたノード(駆動システム・ノードを除く)を含めます。この例では、dbs_groupnode2のみを含める必要があります。

      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
      [root@node1 dbserver_patch_5.180228]# cat dbs_group
      node2
      
  3. パッチ適用の事前チェック操作を実行します。

    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    重要:

    次のステップで実行するバックアップに影響を与える可能性のあるシステムへの変更を防ぐために、-nomodify_at_prereqオプションを指定して事前チェック操作を実行する必要があります。そうしないと、必要に応じてバックアップがシステムを元の状態にロールバックできない場合があります。

    出力は次の例のようになるはずです:

    [root@node1 dbserver_patch_5.180228]# ./patchmgr -dbnodes dbs_group -precheck -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -nomodify_at_prereq
    
    ************************************************************************************************************
    NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
    NOTE
    WARNING Do not interrupt the patchmgr session.
    WARNING Do not resize the screen. It may disturb the screen layout.
    WARNING Do not reboot database nodes during update or rollback.
    WARNING Do not open logfiles in write mode and do not try to alter them.
    ************************************************************************************************************
    2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
    2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
    2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s). 
  4. 現在のシステムをバックアップします。

    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    重要

    これは、システムに変更を加える前にバックアップを取得するのに適切な段階です。

    出力は次の例のようになるはずです:

    [root@node1 dbserver_patch_5.180228]#  ./patchmgr -dbnodes dbs_group -backup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts
    
    ************************************************************************************************************
    NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
    NOTE
    WARNING Do not interrupt the patchmgr session.
    WARNING Do not resize the screen. It may disturb the screen layout.
    WARNING Do not reboot database nodes during update or rollback.
    WARNING Do not open logfiles in write mode and do not try to alter them.
    ************************************************************************************************************
    2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
    2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
    2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
    2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
    2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
    
  5. 更新されるターゲット・コンピュート・ノードからすべてのカスタムRPMを削除します。カスタムRPMは事前チェックの結果でレポートされます。これらには、システムのプロビジョニング後に手動でインストールされたRPMが含まれます。

    ノート

    • バージョン12.1.2.3.4.170111からシステムを更新するときに、事前チェックの結果にkrb5-workstation-1.10.3-57.el6.x86_64が含まれる場合は、これを削除します。(このアイテムは、このバージョンのカスタムRPMとみなされます。)
    • exadata-sun-vm-computenode-exactまたはoracle-ofed-release-guestは削除しないでください。この2つのRPMは、更新プロセス中に自動的に処理されます。
  6. nohupコマンドを実行して更新を実行します。

    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &

    出力は次の例のようになるはずです:

    [root@node1 dbserver_patch_5.180228]# nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -allow_active_network_mounts &
    
    ************************************************************************************************************
    NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
    NOTE
    NOTE    Database nodes will reboot during the update process.
    NOTE
    WARNING Do not interrupt the patchmgr session.
    WARNING Do not resize the screen. It may disturb the screen layout.
    WARNING Do not reboot database nodes during update or rollback.
    WARNING Do not open logfiles in write mode and do not try to alter them.
    *********************************************************************************************************
    
    2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
    2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
    2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
    2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
    2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
    2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
    2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
    2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
    2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
    2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
    2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
    2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
    2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
    2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
    2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. 更新操作が完了したら、更新されたコンピュート・ノード上のカーネルのバージョンを確認します。

    [root@node2 ~]# imageinfo -ver
    18.1.4.0.0.180125.3
    
  8. 駆動システムが、(この例のように)更新が必要なコンピュート・ノードである場合、残りのコンピュート・ノードを更新するために、更新されたコンピュート・ノードを駆動システムとして使用して、この手順のステップ2から7までを繰り返します。この更新例では、node2を使用してnode1を更新します。
  9. 各コンピュート・ノードで、uptrack-installコマンドをrootとして実行して、使用可能なkspliceの更新をインストールします。

    uptrack-install --all -y
    

Exadata Cloud Serviceインスタンスでのツールの更新

Exadata Cloud Serviceのコンピュート・ノードに含まれるクラウド固有のツールを更新するには、最新バージョンのツールを含むRPMファイルをダウンロードして適用します。

ノート

Exadata Cloud Service環境全体で同じバージョンのクラウド・ツールを維持することを強くお薦めます。Exadata Cloud Serviceインスタンスのすべてのコンピュート・ノードで次の手順を実行します。

前提条件

Exadata Cloud Serviceインスタンスのコンピュート・ノードは、Oracle Cloud Infrastructure Object Storageサービスにアクセスするように構成する必要があります。詳細は、オブジェクト・ストレージへのノード・アクセス: 静的ルートを参照してください。

各コンピュート・ノードでのクラウド・ツールの手動更新

ツールを更新する方法は、コンピュート・ノードに現在インストールされているツール・リリースによって異なります。

インストールされているツール・リリースをチェックするには
  1. opcユーザーとしてコンピュート・ノードに接続します。
  2. root-userコマンド・シェルを起動します。

    $ sudo -s
    #
  3. 次のコマンドを使用して、インストールされているクラウド・ツールに関する情報を表示し、リリース・ラベルを書き留めます(次の例の赤色の部分を参照)。

    # rpm -qa|grep -i dbaastools_exa
    
    dbaastools_exa-1.0-1+18.1.2.1.0_180511.0801.x86_64

    この例では、リリース・バージョンは18.1.2.1.0_180511.0801です。

顧客管理の鍵管理をExadata Cloud Serviceに統合

管理する暗号化キーを使用してExadata Cloud Serviceインスタンス内のデータベースを暗号化する場合は、次の2つのパッケージを(Red Hat Package Managerを使用して)更新して、DBAASTOOLSが顧客管理のキー管理で使用されるAPIと対話できるようにします。

KMS TDE CLI

KMS TDE CLIパッケージを更新するには、Exadata Cloud Serviceインスタンスのすべてのノードで次のタスクを完了する必要があります:

  1. 次のように、現在のKMS TDE CLIパッケージをアンインストールします:
    rpm -ev kmstdecli
  2. 次のように、更新されたKMS TDE CLIパッケージをインストールします:
    rpm -ivh kms_tde_cli

LIBKMS

LIBKMSは、PKCS11を介してデータベースを顧客管理キー管理と同期するために必要なライブラリ・パッケージです。新しいバージョンのLIBKMSがインストールされると、データベースが停止して再起動するまで、顧客管理キー管理に変換されたデータベースは以前のLIBKMSバージョンを引き続き使用します。

LIBKMSパッケージを更新するには、Exadata Cloud Serviceインスタンスのすべてのノードで次のタスクを完了する必要があります:

  1. 次のように、LIBKMSパッケージがすでにインストールされていることを確認します:
    rpm -qa --last | grep libkmstdepkcs11
  2. 次のように、新しいバージョンのLIBKMSをインストールします:
    rpm -ivh libkms
  3. 次のように、SQL*Plusを使用して、顧客管理キー管理に変換されたすべてのデータベースを停止して再起動します:
    shutdown immediate;
    startup;
  4. 次のように、すべての変換済データベースで新しいLIBKMSバージョンが使用されていることを確認します:
    for pid in $(ps aux | grep "<dbname>" | awk '{print $2;}'); do echo $pid; sudo lsof -p $pid | grep kms | grep "pkcs11_[0-9A-Za-z.]*" | sort -u; done | grep pkcs11
  5. 次のように、どのデータベースでも使用されなくなったLIBKMSパッケージを削除します:
    rpm -ev libkms