サーバ・ディスク¶
サーバのメンテナンスやスペック変更をサービスの停止無しに行う¶
サーバを運用している間は、以下のような理由によりサーバ停止が必要になる場合があります。
- 脆弱性が改善されたより安全性の高いOSバージョンにアップデート作業を行う
- ローカルネットワークを新設することとなったので接続用の NICの増設 を行う
- より広帯域な回線に接続するため、接続先を共有セグメントから ルータ+スイッチ 配下に移動する
- サーバのCPU処理能力が頭打ちとなったため スペック変更 を行う
このような場合でもサービスを停止することなくサーバを停止させたい場合、 GSLB や エンハンスドロードバランサ を使用した負荷分散アプライアンスを使用する方法があります。これらアプライアンスでは アクセスの多い環境で、その負荷を複数台のサーバに分散させる
のが基本的な目的ですが、 分散先のサーバを常時監視し、応答の無いサーバは分散先から除外する
という可用性を向上させる機能もあり、これを活用することで ロードバランシング先サーバを構成する一部のサーバを停止させてもクライアント側からアクセスが継続できる
ような環境を構築することが可能となります。
エンハンスドロードバランサ を使用した場合の手順は以下のとおりです。
- 停止予定のサーバと、サーバ仕様や設定、内部に保存されるコンテンツなど同等に動作するサーバを作成する
- エンハンスドロードバランサを作成する
- エンハンスドロードバランサの実サーバとして停止予定のサーバと、そのサーバの複製として作成したサーバを追加する
- 2台のサーバに分散して接続されていることを確認し、停止予定のサーバ側をシャットダウンし作業を実行
それぞれのロードバランサごとに、バランシング方式や対応プロトコル、停止検知からバランシング先からの除外までの時間などが異なります。これらの比較については「よくある質問と回答」の 4種類のロードバランサアプライアンスの違いは何ですか? を参照ください。
注意
データベースを参照しリクエストに応じて動的に変化するWebサイトを構築している、コンテンツの参照先となる専用のNFSサーバがあるなど、単純にサーバを並列して動作するだけでは無停止環境を構築できない場合があります。また、参照先をロードバランサのIPアドレスに設定するなど、DNSの更新作業が必要となる場合もあります。
企業サイトなど重要なWebサイトを簡単にHTTPS化する¶
近年のトレンドとして、安全性の向上やクライアント側での表示高速化などを目的としたWebサーバの常時SSL化の流れが進行しており、HTTPを代替するプロトコルとして安全なSSL接続を使用するHTTPSのサポートが標準となりつつあります。大手の検索サイトでもHTTPS接続に対応したサイトはランクが上がったり、HTTP接続のみのサイトではブラウザ側で警告が表示されるといった仕様変更もあり、この流れを後押ししつつあります。
既存のWebサイトをHTTPS対応にする場合、現在幅広く使われるWebサーバアプリケーションではほとんどの場合においてSSL接続を実現するHTTPSプロトコルにも対応していますが、単純なサーバの設定変更のみならずSSL証明書の入手とインストールが必要となるため、HTTPのみのサーバと比較し、より多くの手間と時間が必要となります。また、定期的な証明書の更新といった運用開始後の管理コストも増大しがちです。
そこで、HTTPS接続をアプライアンスのひとつの機能として提供する エンハンスドロードバランサ を使用し、現在のWebサーバへ手を加えることなく、また自動的に証明書が設定可能なLet’s Encrypt認証局発行の証明書を使用した常時SSL化を実現する方法を紹介します。
注釈
エンハンスドロードバランサで自動設定が可能なLet’s Encrypt認証局が発行する証明書はドメイン認証型となり、通信の暗号化やHTTP/2通信による高速転送などの機能に限った利用を行う場合に有効です。組織の実在証明などさらに安全性を高めたい場合は企業認証やEV認証型の証明書を購入することをおすすめします。
現在の構成と、完成後の構成¶
現在の構成として、Webサーバ1台が外部から接続可能なグローバルネットワークに接続され、HTTPによるサービスを行っている環境を想定します。
この構成に エンハンスドロードバランサ を新たに追加します。
これにより、
- 外部からの接続先はエンハンスドロードバランサのIPアドレス(VIPアドレス)
- エンハンスドロードバランサにはHTTPS接続を使用する
- 接続があると既存のWebサーバにHTTP接続し、取得したコンテンツをそのままクライアントに返答する
という流れに変化します。つまり、エンハンスドロードバランサがHTTPSで応答することにより、既存のWebサーバに手を加えることなくHTTPS接続環境が実現できます。具体的な手順は以下の通りとなります。
- エンハンスドロードバランサを新規に作成
- エンハンスドロードバランサの実サーバに既存のWebサーバを登録
- エンハンスドロードバランサの待受ポートにHTTPS/443番ポートを設定
- DNSを変更し、Webサーバに設定されていたホスト名をエンハンスドロードバランサのVIPに変更する
詳しくは エンハンスドロードバランサ のページを参照ください。
注意
クライアント側の接続先はエンハンスドロードバランサに付与されるVIPとなるためDNS変更が必要となります。また、既存のサーバに付与されたIPアドレスをエンハンスドロードバランサのIPアドレスとして使用することはできません。
大量のサーバを同時にOSインストールして、終わったらすぐにログインできるようにしたい¶
負荷分散用のクラスタや一時的に使用するVDI用など、同一のスペック・同一ディスク内容のサーバを大量に作成したい場合は サーバ新規作成 フォームでサーバ作成数の項目を複数指定することで、一度の操作で同時に作成することが可能です。
作成した複数のサーバは ディスク修正機能 機能によりIPアドレスやホスト名などのネットワーク情報が自動的に個々の設定に変更されますが、パスワードは同一のものとなり、安全性が低下する可能性があります。そこでディスク修正機能では公開鍵情報の変更機能が備わっており、作成時に自動的に公開鍵が設定された状態で作成を完了させることができます。特に管理者がすでに公開鍵認証で管理対象のサーバを管理している場合、サーバ作成後もすぐに他のサーバと同様の手順で安全に接続することができて便利です。
公開鍵は、作成時のフォームに直接入力する、 コントロールパネルにあらかじめ登録しているものを選択 、GitHubのユーザ名から登録済みの公開鍵を取得する…のいずれかの方法より選択可能です。詳しくは ディスク修正機能 のページを参照ください。
サーバやアプライアンスをうまくシャットダウンできない場合の対処方法¶
サーバやアプライアンスでは、通常はサーバにログインしてシャットダウンコマンドを実行したり、コントロールパネルの 電源操作 で「シャットダウン」を選択してACPIから仮想的に電源ボタンを押下した状態をエミュレートすることでシャットダウンが可能です。
通常はこれらの操作でサーバの停止や再起動を行うことを推奨しますが、OSが高負荷状態にあったり、暴走している、フリーズしているなど異常な状態にあるとこれらの操作で電源が停止しない場合があります。その際は「強制停止」または「強制リブート」を選択します。
警告
「強制リブート」・「強制停止」は仮想的に電源断状態を再現するため、保存されていない情報は失われたり、次回の起動時にうまく動作しない可能性があるのでご注意ください。アプライアンスはお客様がログインして操作できないため、もし強制操作による停止後にうまく起動しない場合は サポート までご連絡ください。
セットアップが完了したサーバと同じディスクのサーバを複数台作りたい¶
1台のサーバを作成し、その後アプリケーションのインストールや設定作業まで完了したサーバをテンプレートとして同一のサーバを大量に作成したい場合は、作成したサーバのディスクを アーカイブ として保存し、それを新規サーバ作成時のディスクへのコピー元として指定することで実現できます(1台だけ必要な場合は直接ディスクからコピーすることも可能です)。
注意
アーカイブにコピーした場合、別途アーカイブ利用料金が発生します。また、ディスクへのコピー元としてマイアーカイブを指定した場合は ディスク修正機能 をご利用いただけません
古いOSのインストール時にディスクが認識しない場合の対処方法¶
古いOSを使用する必要があり、独自にそのOSのインストールディスクのイメージをサーバの仮想CD-ROMドライブに挿入可能な ISOイメージ としてアップロードしてインストールを行うなどの場合、ディスクがうまく認識しないことがあります。現在さくらのクラウドではディスクの接続に標準でVirtIOが選択されているため、VirtIOドライバに対応しないOSの場合はディスクが認識できなくなるためです。
そのため、新規作成時に「準仮想化モードを使う」のチェックを外す
または、ディスクを選択し、上部の「その他のディスク操作」メニューから「接続インターフェース変更」を選択し、VirtioからIDEに変更します。
注意
接続インターフェースを変更する場合はサーバの停止が必要です。
サーバの接続が遅いとき¶
アクセスの増大などによりサーバへの接続や応答が以前と比較して遅くなっている場合はいくつかの原因が考えられます。大きな切り分け方法としては
- サーバのOS・アプリケーションに問題がある場合
- 仮想サーバ、ネットワークなどインフラ(クラウドリソース)側に問題がある場合
に大別できます。項目1番目のサーバのOSやアプリケーションの問題については実際にサーバにログインして調査する必要がありますが、ここではコントロールパネルから、項目2番目の仮想サーバやネットワークなどインフラ側に問題があるかどうかを判断する際のポイントについて解説します。
アクティビティグラフ¶
アクティビティグラフ では、各リソースのネットワークトラフィックやCPU負荷状況など、クラウド基盤側で観測可能な種々のデータを時系列のグラフで参照することができます。以下のような事象が見られる場合と、その際考えられる原因については以下のような例があります。
- NICのトラフィックの増大→ネットワーク帯域がボトルネックの可能性
- CPU使用時間の増大→CPUがボトルネックの可能性
- ディスクI/Oの増大→ストレージ帯域がボトルネックの可能性
これらの場合に対応する方法は以下の通りです。
- 共有セグメントから ルータ+スイッチ への接続変更、ルータ+スイッチの帯域増速
- プラン変更機能 でサーバに搭載のCPUコア数やメモリがより大きなプランに変更
- SSDプランディスクや大容量ディスクへの移行(ディスク容量が大きいほど IOPSなどに余裕を持たせた設計 となっています)
シンプル監視機能のレスポンスタイム確認機能¶
さくらのクラウド内のサーバに対するpingやhttpなどの監視を行える シンプル監視 では レスポンスタイム確認機能 が備わっており、アクティビティグラフと同様にグラフで確認が行えます。特定の時間帯のみレスポンスタイムが大きくなる、レイヤの低いpingの応答速度に変化はないがhttpやftpなどのアプリケーションのレスポンスが大きくなるなど、ボトルネックの究明に役に立ちます。