TECH PLAY

SCSKクラウドソリューション

SCSKクラウドソリューション の技術ブログ

1232

こんにちは SCSKの庄司です。 今回は基本的な機能ではありますが意外と知らない人も多い、レコードを一括更新する方法を紹介していきます。 本記事は執筆時点(2025年7月)の情報になります。最新の内容は製品ドキュメントを参考にしてください。 CtrlまたはShiftキーを使用したリストエディターの活用 まずは最も手軽な方法を紹介します。 手順: ①リスト画面を開き、CtrlキーもしくはShiftキーを押下しながら更新対象となるレコードの対象フィールドをクリックして選択します。 Ctrl:任意のレコードを個別に選択 Shift:隣接するレコードを範囲選択 青色に変更されたフィールドが、選択中のフィールドです。 CtrlとShiftの違いとしては、Ctrlは複数選択、Shiftは範囲選択であるという点です。 具体的には、Ctrlは飛ばし飛ばしで任意のレコードを個別に選択できます。 一方で、Shiftは隣接するレコード間を範囲選択します。 ExcelでのCtrlとShiftキーでのセル選択をイメージしていただければわかりやすいと思います。 ②選択中のフィールドの中の任意のレコードをダブルクリックします。 リストエディター画面に選択中のフィールドの数が表示されています。 ③更新内容を入力します 今回は、「アサイン先グループ」を「Hardware」に変更します。 ④保存を押下します 更新後、先ほど選択したすべてのレコードが更新されていることがわかります。     注意: この方法は最も簡単にレコードを一括更新できるものの以下のような制約があります。 ・一度に更新できるフィールドは一項目のみ ・リスト上に表示されているレコードの範囲までしか更新できない(最大100件)   「すべて更新」 「すべて更新」を使うと、一括でテーブル上のすべてのレコードを更新することもできます。 手順: ①コンテキストメニューを開き、「すべてを更新」を選択します。 ②更新対象のレコード数が表示されるので、よければOKを押下します。 この更新対象は現在のリスト上のすべてのレコードになりますので、フィルター条件を使用することで更新対象を変更することが出来ます。 今回は「アサイン先グループ」が「Hardware」のレコードを一括更新します。 ③フォーム画面が表示されるので、この画面で対象レコードに対して一括で更新したい内容を記載します。 今回は、「アサイン先グループ」を「Software」、「アサイン先」を「Beth Anglin」に変更します。 ④[更新]を押下すると、画面がリスト画面に遷移します。 「複数の更新が完了しました。合計レコードが更新されました:21」というメッセージが表示されています。 対象レコードが更新されたので「アサイン先グループ = Hardware」のレコードがなくなっています。 「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」でフィルタリングすると、先ほどは「アサイン先グループ = Hardware」だったレコードたちが出てきました。 注意: この更新方法だと、上限なくレコードを一括更新ができます。 ただし、気を付けなければならないのはすべてのレコードを目視で確認することはできない点です。 フィルター条件を間違えてしまうと意図しないレコードまで更新することになってしまうので注意が必要です。   「プレビューですべて更新」 「プレビューですべて更新」は、より安全にレコードの一括更新をすることが出来ます。 手順: ①コンテキストメニューを開き、データ管理>プレビューですべてを更新を押下します。 ②データ管理更新ジョブレコードが作成され、表示されます。 以下、このレコードの要点となるフィールドについて説明します。 ・ 条件 :一括更新対象とするレコードのフィルター条件 今回は「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」でフィルタリングした状態からフィルタリングした状態から[プレビューですべてを更新]を選択したので最初から入力されていますが、データ管理更新ジョブレコード上からフィルタリング条件を変更することもできます。 条件を記入した後[プレビュー]を押下すると、その条件に応じたレコードの数を表示してくれます。 更新対象となるレコードに間違いがないように、「条件」にはよく注意しましょう。 ・ フィールドと値 :更新対象レコードに対して更新をかけるフィールドとその値 今回は「アサイン先グループ」を「Hardware」に、「カテゴリ」を「ハードウェア」に変更します。    実行場所 :レコード一括更新の実行日時を定義します。 手動で更新を実施するので、今回は空欄のままにします。 ③必要事項を記入した後、[保存]を押下します。 ④保存後、関連リンク[今すぐ実行]を押下します。 ⑤更新の実行前に警告が出てきますので、問題なければ[続行]を押下します。 以上の手順で更新が完了しました。 ではインシデントテーブルを見に行きます。 「アサイン先グループ = Hardware」かつ「カテゴリ = ハードウェア」かつ「更新日時 = 今日」をみると、先ほどまで「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」だったレコードたちが表示されています。        「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」を見に行くと、レコードがなくなっています。 以上が「プレビューですべて更新」です。 基本的には手順が少し変わるだけで、やっていることやできることは先ほど紹介した「すべて更新」と変わりません。 ただし、一点大きく異なる箇所があります。 それは、「ロールバック」ができる点です。 以下、ロールバックの手順を紹介します。 ロールバック手順: ①先ほどのレコード更新完了画面から、[実行結果を確認]を押下すると、データ管理更新ジョブレコードが開きます。 開いたデータ管理更新ジョブレコードを見ると、「状況」が「完了」、「実行場所」が実行した日時になっています。 そして、先ほどは[すぐに実行]が表示されていた関連リンクに[ロールバック]が表示されています。 ②関連リンク[ロールバック]を押下すると、本当にロールバックを実施するかというポップアップが出てきますので、問題なければ[ロールバック]を押下します。 ③ロールバックが完了しました。 データ管理更新ジョブレコードの「状況」が「ロールバック済み」に変更されています。 では、リストを見に行きます。 ロールバック前とは異なり、「アサイン先グループ = Hardware」かつ「カテゴリ = ハードウェア」かつ「更新日時 = 今日」でフィルタリングしてもレコードがありません。 逆に、「アサイン先グループ = Software」かつ「アサイン先 = Beth Anglin」かつ「更新日時 = 今日」をみると先ほどのレコードたちが表示されています。     これがロールバックになります。 更新対象を間違えて一括更新してしまった際などに、更新内容を取り消すことが出来る非常に便利な機能です。 注意: 「プレビューですべて更新」も「すべて更新」同様、対象レコードを目視で確認できないので対象が間違っていないかは要確認です。 フィルター条件を間違えてしまうと意図しないレコードまで更新することになってしまいます。 「プレビューですべて更新」ならロールバックで戻すことはできますが、安易な一括更新は避けて慎重に実行するようにしましょう。   「選択項目を更新」 「選択項目を更新」を使うと、「プレビューですべて更新」や「すべて更新」とは異なりフィルタリングしたレコードではなく、選択したレコードに対して一括更新することができます。 手順: ①インシデントテーブルで更新対象とするレコードを選択します。 今回は「アサイン先」が「ATF User」になっているレコードをの中から「カテゴリ」が「ハードウェア」になっているレコードを更新対象とします。   ②選択後、コンテキストメニューを開き、[選択項目を更新]を選択します。 ③フォーム画面のような画面が開きますので更新内容を入力します。 ここからは先ほど紹介した[すべてを更新]と同じです。 今回は、カテゴリをデータベースにしてみましょう。 ④入力後更新を押下します。 画面が遷移し先ほど選択したレコードの「カテゴリ」が「データベース」に更新されています。  注意: こちらの方法は対象レコードを選択する必要があるため、リスト上に表示されているレコードの範囲までしか更新できません(最大100件) また、一括選択する場合を除き、選択の手間もかかるため大量のレコードの一括更新にはお勧めできません。   まとめ 以上が、リスト画面からレコードを一括更新する方法です。 どれも簡単な作業ですが非常に有用な機能ですので、ぜひ使ってみてください。
こんにちは  SCSK 野口です。 前回の記事 『LifeKeeperの「Quorum/Witness」とは』 では、 Quorum/Witnessの種類とパラメータについてご紹介いたしました。 まだ、お読みでない方は上記リンクからご覧ください。 本記事では、 Quorum/Witness(Storage) を仮想マシン上のLinux環境に導入してみます。 今回、共有ストレージには「blockタイプ」を採用します。 おさらい 前回の記事でもお伝えしましたが、共有ストレージは各ノードからアクセス可能なストレージのことです。 Quorum/Witness機能専用で使用する共有ストレージは、LifeKeeperリソースとして保護することはできません。 あくまでもスプリットブレインを回避する機能のために使用します。 Storageモードでは、下記3つの共有ストレージの種類(タイプ)が選択できます。 ・block………共有ストレージに物理ストレージやRDM(物理互換)、iSCSI(VM 内イニシエーター)を使用する場合 ・file…………共有ストレージにNFS (または Amazon EFS) を使用する場合 ・aws_s3……共有ストレージに AmazonのS3 、または Amazon S3互換のオブジェクトストレージを使用する場合 ※ Windowsの場合は、blockタイプはありません。 ちなみに Storageモード は、 2ノード以上4ノード以下 から 利用可能よ! でも、 クラスター内に  ” – ”  と  ” . ”  だけ異なるホスト名の ノードが存在する場合 は Storageモードが利用できないよ。 例えば、 クラスター内に 「  node-1  」 と 「  node.2   」 が存在する場合はホスト名を変更してね! 導入 今回の構成について 今回の構成では Virtual Box(仮想VM)を使用し、2台のサーバ(ノード)構成にします。 また、共有ストレージについては VDI(Virtual Disck Image)を使用していきます。 そして、1QWKオブジェクトあたり必要な容量は  4096 バイト (4 KB ) となります。 「QWK_STORAGE_TYPE」を blockタイプにした場合、QWK オブジェクトの配置場所は以下となります。 今回は2台のサーバ(ノード)だから、 QWKオブジェクトに必要な容量は 8192バイト(8KB)だよ! 2つのパーティションを用意する必要があるんだね! 動作環境 今回の Qurum/Witness(Storage構成) を導入した構成は以下となります。   一般的な  Active/Standby 構成ね 稼働系ノードの障害時に待機系ノードにサービスを引き継ぐんだよね! 導入手順 1.サーバをセットアップし、他のサーバとネットワーク通信ができることを確認します。 ※ サーバセットアップの詳細は省かせていただきます。 サーバ間で通信できているか、お互いに pingコマンドで疎通確認してみます。 [root@rhel75n01 ~]# ping -c 3 rhel75n02 PING rhel75n02 (~.~.~.~) 56(84) bytes of data. 64 bytes from rhel75n02 (~.~.~.~): icmp_seq=1 ttl=64 time=1.68 ms 64 bytes from rhel75n02 (~.~.~.~): icmp_seq=2 ttl=64 time=0.943 ms 64 bytes from rhel75n02 (~.~.~.~): icmp_seq=3 ttl=64 time=0.960 ms — rhel75n02 ping statistics — 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.943/1.194/1.681/0.346 ms [root@rhel75n02 ~]# ping -c 3 rhel75n01 PING rhel75n01 (~.~.~.~) 56(84) bytes of data. 64 bytes from rhel75n01 (~.~.~.~): icmp_seq=1 ttl=64 time=1.49 ms 64 bytes from rhel75n01 (~.~.~.~): icmp_seq=2 ttl=64 time=0.913 ms 64 bytes from rhel75n01 (~.~.~.~): icmp_seq=3 ttl=64 time=0.909 ms — rhel75n01 ping statistics — 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 0.909/1.106/1.496/0.275 ms 2.サーバに LifeKeeper をインストールします。 その際、「Use Quorum/Witness functions」を有効にし、Quorum/Wintness パッケージをインストールします。 3.全てのノード間でコミュニケーションパスを作成し、ALIVEであることを確認します。 今回は LKWMCなので、左タスクバーの「コミュニケーションパス」を選択します。 ※ コミュニケーションパス(ハートビート)が1つの場合、「リソースツリー」画面では警告が表示されます。 コミュニケーションパスのステータスが「ALIVE」であることを確認します。 4.すべてのノードで Quorum/Witness の設定を行います。(/etc/default/LifeKeeper) ※ パラメータについては、冒頭でお話しした記事を参照してください。 [root@rhel75n02 ~]# vi /etc/default/LifeKeeper QUORUM_MODE= storage             # デフォルト値は majority です                        # What style of quorum verification do we do in comm_up/down                        # and lcm_avail (maybe other) event handlers.                        # NOTE: This only matters of the quorum support is installed                        #            (the steeleye-lkQWK package).                        # The possible values are:                        #  – none/off: Do nothing, skip the check, assume all is well.                        #  – majority: Verify that this node and the nodes it can reach                        #                   have more tha half the cluster nodes.                        # – tcp_remote: Verify that this node can reach more than half                        #                      of the QUORUM_HOSTS via tcp/ip.                        # – storage: Verify by the QWK storage protocol (requires                        #                 additional configuration). WITNESS_MODE= storage              #デフォルト値は remote_verify です                        # This can be either off/none, remote_verify or storage.                        # In remote_verify mode, core event handlers (comm_down) will                        # double check the death of a system by seeing if other visible                        # nodes also think it’s dead.                        # In storage mode, core event handlers (comm_down) will check                        # the death of a system by the QWK storage protocol. なお、Storageモードを利用しているため、必要なパラメータは設定ファイルの末尾に追加します。 # Do NOT edit LK_DISTRIBUTION values – this may cause LifeKeeper to malfunction LK_DISTRIBUTION=redhat LK_DISTRIBUTION_VERSION=7.5-8.el7ON_VERSION=7.5-8.el QWK_STORAGE_TYPE=block                         #(必須)追記 QWK_STORAGE_HBEATTIME=6                     #(任意)追記しない場合はデフォルト値 (6)となる QWK_STORAGE_NUMHBEATS=4                    #(任意)追記しない場合はデフォルト値 (4)となる QWK_STORAGE_OBJECT_rhel75n01=/dev/sdc1     #(必須)追記 QWK_STORAGE_OBJECT_rhel75n02=/dev/sdc2     #(必須)追記 「QWK_STORAGE_OBJECT _ <ホスト名>」 のパラメーターは、 ホスト名に” – ”  と  ” . ”  を含む場合、 ” _ ” (アンダースコア)に置き換えてください! 「  node-1  」と「  node-2  」や「  node.1  」と「  node.2 」の場合は、 「 node_1 」と「 node_2 」に置き換えて追記すればいいんだね! 1号機(rhel75n01)からqwk_storage_init コマンドを実行します。 ※ 「QWKオブジェクトとして既に存在しますが上書きしますか?」 と問われるので ”y” を入力し、[Enter] を押します。 [root@rhel75n01 ~]# /opt/LifeKeeper/bin/qwk_storage_init ok: LifeKeeper is running. ok: The LifeKeeper license key is successfully installed. ok: QWK parameter is valid. QWK object of /dev/sdc1 is not yet avail. /dev/sdc1 already exsits as not QWK_STORAGE_OBJECT: overwrite? (y/N): y すると、全ノードで QWK オブジェクトの初期化が終わるまで待ち状態になります。 [root@rhel75n01 ~]# /opt/LifeKeeper/bin/qwk_storage_init ok: LifeKeeper is running. ok: The LifeKeeper license key is successfully installed. ok: QWK parameter is valid. QWK object of /dev/sdc1 is not yet avail. /dev/sdc1 already exsits as not QWK_STORAGE_OBJECT: overwrite? (y/N): y ok: The path of QWK object is valid. ok: down: /opt/LifeKeeper/etc/service/qwk-storage: 2764s ok: Initialization of QWK object of own node is completed. QWK object of /dev/sdc2 is not yet avail. QWK object of /dev/sdc2 is not yet avail. QWK object of /dev/sdc2 is not yet avail. 2号機(rhel75n02)からも qwk_storage_init コマンドを実行すると、 2号機(rhel75n02)1号機(rhel75n01)ともに 「 Successful. 」 と出力されます。 ※ 1号機(rhel75n01)と同様のことを問われるので ”y” を入力し、[Enter] を押します。 [root@rhel75n02 ~]# /opt/LifeKeeper/bin/qwk_storage_init ok: LifeKeeper is running. ok: The LifeKeeper license key is successfully installed. ok: QWK parameter is valid. QWK object of /dev/sdc2 is not yet avail. /dev/sdc2 already exsits as not QWK_STORAGE_OBJECT: overwrite? (y/N): y ok: The path of QWK object is valid. ok: down: /opt/LifeKeeper/etc/service/qwk-storage: 2788s ok: Initialization of QWK object of own node is completed. ok: quorum system is ready. ok: run: /opt/LifeKeeper/etc/service/qwk-storage: (pid 5152) 1s, normally down Successful. ちなみに初期化後のログを確認したところ、以下のようなメッセージが出力されます。 Jul 15 17:39:43 rhel75n01 runsv[4974]: INFO:runit:::013008:qwk-storage server is starting up Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135805:starting qwk_storage_server Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135848:[rhel75n01:/dev/sdc1] invalid qwk object was found. initializing to sequence 0. Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135848:[rhel75n02:/dev/sdc2] invalid qwk object was found. initializing to sequence 0. Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135923:[rhel75n01:/dev/sdc1] qwk object was restored. Jul 15 17:39:43 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135924:quorum state changed to AVAIL. Jul 15 17:39:55 rhel75n01 qwk_storage_server[4973]: INFO:qwk:::135923:[rhel75n02:/dev/sdc2] qwk object was restored.   この手順が完了すると、クラスターにおいて Quorum および Witnessの機能が有効化されるわ! フェイルオーバーが実行される前に Quorumチェック と Witnessチェックが実施されるよ!! ちなみに、 共有ストレージにアクセスできなくなるとリソースの起動に影響するよ。 だから、 すべてのノードから常時アクセス可能な共有ストレージが必要だよ! 動作確認 QWKオブジェクトが指定された間隔で更新されているか、実際に確認してみます。 更新間隔は/etc/default/LifeKeeper に記載される  QWK_STORAGE_HBEATTIME(デフォルト6)で定義されます。 1号機(rhel75n01)から ddコマンドを 2回実行し、QWK オブジェクト1が更新されているか確認してみます。 ※ 2回目の ddコマンドを実行する際は、指定された時間と同じくらい間隔をあけてください。 [root@rhel75n01 ~]# dd if=/dev/sdc1 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.0016561 秒、 2.5 MB/秒 signature=lifekeeper_qwk_object local_node=rhel75n01 time=Fri Jul 16 01:31:15 2025 sequence=8651 node=rhel75n02 commstat=UP checksum=9659698734818933381       [root@rhel75n01 ~]# dd if=/dev/sdc1 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.00232737 秒、 1.8 MB/秒 signature=lifekeeper_qwk_object local_node=rhel75n01 time=Fri Jul 16 01:31:21 2025 sequence=8652 node=rhel75n02 commstat=UP checksum=9659699284571077253 1号機(rhel75n01)からQWK オブジェクト2(/dev/sdc2)も確認してみます。 ※ 2号機からの確認は省かせていただきます。 [root@rhel75n01 ~]# dd if=/dev/sdc2 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.0110848 秒、 370 kB/秒 signature=lifekeeper_qwk_object local_node=rhel75n02 time=Fri Jul 16 01:50:10 2025 sequence=8833 node=rhel75n01 commstat=UP checksum=9643936960751614597       [root@rhel75n01 ~]# dd if=/dev/sdc2 bs=4096 count=1 | strings 1+0 レコード入力 1+0 レコード出力 4096 バイト (4.1 kB) コピーされました、 0.000993328 秒、 4.1 MB/秒 signature=lifekeeper_qwk_object local_node=rhel75n02 time=Fri Jul 16 01:50:16 2025 sequence=8834 node=rhel75n01 commstat=UP checksum=9643937510513719941 両ノード( rhel75n01 と rhel75n02 )のタイムスタンプは同じになるとは限らないわよ なお、 Quorum/Witness(Storage) を導入しているサーバでは、 OS起動後にログを確認すると以下のようなメッセージが出力されます。 Jul 1 6 10:13:05 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135857:[rhel75n02:/dev/sdc2] lcd sys state: UP (It looks the same from its own node and from the target node.) Jul 1 6 10:13:05 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135863:[rhel75n02:/dev/sdc2] remote node up (status=CR1) Jul 1 6 10:13:05 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135866:quorum_verify(LCM_AVAIL, ): AVAIL Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135857:[rhel75n02:/dev/sdc2] lcd sys state: UP (It looks the same from its own node and from the target node.) Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135863:[rhel75n02:/dev/sdc2] remote node up (status=CR1) Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135866:quorum_verify(COMM_UP, rhel75n02): AVAIL Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135868:witness_verify(COMM_UP, rhel75n01): UP Jul 1 6 10:13:14 rhel75n01 qwk_storage_server[2960]: INFO:qwk:::135868:witness_verify(COMM_UP, rhel75n02): UP まとめ 今回は Quorum/Witness を実際に導入してみましたがいかがでしたか。 導入する際は、以下の点に注意してください。 ・共有ストレージの種類は、3つから選択ができる。(Windowsの場合は2つから選択) ・導入する前に、ホスト名やノード数に細心の注意を払う。 ・導入する際は、コミュニケーションパスが Aliveであることを確認する。 ・動作確認では、指定された間隔で更新されているかタイムスタンプを確認する。   詳細情報をご希望の方は、以下のバナーからSCSK Lifekeeper公式サイトまで
Cato Networks社が今年(2025年)で3回目となるパートナーサミット「Japan Partner Summit Tokyo 2025」が、2025年7月15日(火)に開催されました。 SCSKは、 新規顧客の売り上げに最も貢献したパートナー として「 Japan Highest New Logo Revenue 2024 」と、 最も卓越したサポートを提供し、お客様の満足度向上に貢献したパートナー として「 Japan Best Technical Support Partner 2024 」の2つのアワードを受賞いたしました。 日本でパートナーサミットが2023年に開始されてから 3年連続のアワード受賞 となり、今年度はアワードの ダブル受賞 となりました。 2025年度 https://www.scsk.jp/news/2025/pdf/20250722i.pdf 2024年度 https://www.scsk.jp/news/2024/pdf/20240722i.pdf 2023年度 https://www.scsk.jp/news/2023/pdf/20230726i.pdf アワードが意味するところ 「 Japan Highest New Logo Revenue 2024 」アワードが示すように、これから新しくCatoクラウドのご検討を開始されるお客様は、まずはSCSKまでお問い合わせください。 正しいCatoクラウドのサービスのご紹介、ご理解の支援から、お客様の環境へCatoクラウドを適用する際の不安や懸念点、移行に関わる疑問点などを、多くの導入実績をもとにした最適な回答を行うことが可能です。 もちろん事前検証となるPoC(概念実証)のご支援も実施しております。 ご好評いただいているCatoクラウドの FAQサイト や、本 技術ブログ(TechHarmony) 記事など、いちいち当社へ問い合わせをすることなく、可能な限りお客様自身が自己解決を行うことができるように各種デジタルコンテンツを充実しておりますので、非常にタイムパフォーマンスが高いPoCを行うこと可能となっております。 Catoクラウドのサービスの紹介を受けたが、メリットがよく分からない。他のSASEソリューションとの違いがよく分からない。自社へ適用するにはどうすれば良いか分からない。などがあれば、ぜひ お問い合わせ ください。 次に「 Japan Best Technical Support Partner 2024 」のアワードが示すように、SCSKとご契約いただいたお客様には、日本語での技術問い合わせを始めとし、各種マネージドサービスをご提供しております。これらのサービスが卓越したサポートで、お客様の満足度向上に貢献したとの評価をいただきました。 PoCと同様ですが、FAQサイトや、技術ブログ記事など、各種デジタルコンテンツも充実させており、また、Catoクラウドのドキュメント(Knowledge)は殆どが英語となるため、独自のAIチャットボットもご提供しております。 AIチャットボットに、日本語での自然語検索を行い、Cato公式文書(英語)や、FAQサイト、技術ブログなどを一括検索し、検索結果を回答するとともに、その情報引用元もご提供します。 「SCSK Cato クラウド AI チャットボット」をリリースしました SCSKが開発した「Catoクラウド AIチャットボット」の機能・利便性・導入効果をご紹介します。 blog.usize-tech.com 2025.02.14 また、Cato社のサポート認定「 Cato Distinguished Support Providers(CDSP) 」認定も受けております。 CatoクラウドのCDSP(Cato Distinguished Support Providers)認定を取得 Catoクラウドの戦略的パートナーとしてのCDSP(Cato Distinguished Support Providers)認定取得と、お客様におけるメリットについて解説しています。 blog.usize-tech.com 2024.03.04 SCSKでは、Cato社の上級エンジニアに直接問い合わせが行えますので、当社へお問い合わせいただいた課題については、より早く、より質の高い回答が行うことが可能となっております。 Catoクラウドを現在ご利用中で、何かお困りごとがあるお客様が居れば、ぜひ一度SCSKまで お問い合わせ ください。 最近は、Catoクラウドのユーザーコミュニティ(ユーザ交流会、ユーザ会)である「 Cato Circle(ケイトサークル )」を発足いたしました。 Catoクラウド ユーザーコミュニティ「Cato Circle」を発足しました! Catoクラウド ユーザーコミュニティ「Cato Circle(ケイトサークル)」の発足についての記事となります。 blog.usize-tech.com 2025.07.02 Cato Circleは、ユーザーコミュニティなので、通常の企業セミナーのように、一方的に説明を行う「説明型」イベントではなく、利用者であるお客様が、Catoクラウドの自社での活用方法や、利用上の課題を発表し、利用者同士が情報を共有する「双方向型」のイベントを企画しております。 お客様同士の交流、ネットワーク構築から、情報交換のきっかけをご提供し、課題や悩みを共有し、解決するヒントを得ていただくことが Cato Circle の目的となっております。   まとめ 日本国内でも「SASE(Secure Access Service Edge、サッシー)」や、「Cato Networks(ケイトネットワークス)」、「Catoクラウド(正式名称 Cato SASE Cloud Platform)」の認知度は徐々に上がって来ておりますが、まだ低い状況です。 2023年、2024年と品川駅の自由通路にて屋外広告を出稿していましたが、2025年も6月と7月にそれぞれ1週間広告出稿しました。 SCSKでは、2021年からSASEの主要な4ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit(通称 S4 エスフォー)」を定期的に開催しております。これまで15回開催し、述べ2,000名以上の方にご参加いただいております。 また、Catoクラウドにおいても、デモセミナー(オンライン)、ハンズオンセミナー(オフライン)なども定期的に開催しておりますので、ご興味ある方は、ぜひご参加ください。 Catoクラウド イベント・セミナー情報 | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK 定期的にCatoクラウドをご紹介するセミナーを開催しております。・2024年9月26日(木)Catoクラウド ハンズオンセミナー【札幌開催分】 ~全国5都市開催(東京/大阪/名古屋/博多/札幌)~ ... cato-scsk.dga.jp SASEセミナー、Catoクラウドセミナー以外に、Catoクラウドの お客様導入事例 の制作、 FAQサイト 運営、この TechHarmony(技術ブログ)で、Catoクラウドの日本語のお役立ちサイトを目指し、Catoクラウド、SASEの認知度向上と、皆様のお役に立てればと考えております。 Catoクラウドに少しでも興味をお持ちになられた方は、ぜひ当社まで お問い合わせ ください。 Catoクラウド エンジニアブログまとめ記事 Catoクラウドのエンジニアブログ(TechHarmony)でのまとめ記事となります。 blog.usize-tech.com 2024.02.27
Catoクラウドの3つのファイアウォール機能の一つ、「LAN Firewall」の設定方法の紹介記事です。 2025年7月の機能リニューアルに準拠した操作方法、注意事項を説明いたします。 はじめに:LAN Firewallとは? Catoクラウドは、以下の通り3種類のファイアウォール機能を有しています。 名称 役割 Internet Firewall Catoのネットワークを経由してインターネットへ接続する際のアクセス制御 WAN Firewall Catoのネットワークを経由する、拠点内リソースへのアクセス制御 LAN Firewall Catoのネットワークを 経由しない 、Socket経由での拠点配下の通信の制御 上記の通り、LAN Firewallは「Catoのプライベートバックボーンを経由させない」 挙動をとることができるという特徴があります。 CatoのSocketはVLANの管理用機能も有しているため、 部門や機能ごとにセグメントを分けて、各セグメント間の通信は拒否させる サーバ用セグメントに存在する特定のサーバだけは接続可能とする といった、拠点内の通信制御としてよく見られる機能をCatoクラウドで完結させることが可能です。 LAN Firewall自体は従来からCatoの一機能として存在していましたが、 本機能は2025年7月に大規模なリニューアルが実施されました。 従来のLAN Firewallを設定していた場合、Catoによる設定の自動移行が実施されます 。 移行後は本記事の記載にあるような形で設定の確認・変更を行うことになるのでご注意ください。 LAN Firewallの設定 設定画面と2つの「Rule」 従来、LAN Firewallの設定は各Sitesの設定画面から個別に管理する必要がありました。 2025年7月のアップデートにより、LAN Firewallの設定は[Security] > [Firewall]配下に移動されました。 3種類のファイアウォールがメニュー上で並ぶようになり、直感的にわかりやすい配置となりました! LAN Firewallには、異なる役割を持つ2つのルールが存在します。 それぞれの設定方法について、以降のセクションにて説明していきます。 名称 役割 Network Rule 「どの通信をLAN Firewallでの制御対象とするか」を設定するルールです。 このルールで定義されていない通信は、WAN Firewallの適用対象になります。 Security Rule 条件に応じて通信の許可/ブロックを指定するルールです。 一般的にイメージされるファイアウォールのルールがこちらです。 「Network Rule」の配下に配置され、 親にあたる「Network Rule」の条件を満たす通信にのみ適用 されます。   Network Ruleの作成 リニューアルされたLAN Firewallですが、従来通り「暗黙のWAN転送」の仕様が採用されています。 つまり、 「LAN経由」とルールで指定されていない通信は全てCato PoPへ転送され、他のSite宛の通信と同様にWAN Firewallを経由してから元のSiteへ再転送 という挙動をとることになります。 この、「どの通信はWANを経由させないか」を指定するルールが「Network Rule」です。 [Security] > [Firewall] > [LAN Firewall]にて、 [LAN Firewall]タブの「New > New LAN Network Rule」を選択すると新規作成が可能です。 項目名 役割 General ルールの名前や配置位置、適用する通信方向を定義します。 他のファイアウォールと同様のものです。 Site 適用対象とするSiteを指定します。デフォルトだと「Any」となっていますが、 デフォルトのままだと文字通り「全てのSite」に適用 されてしまいます。 例えば、VLAN IDを用いて通信を制御するルールを作成したとして、 同名のVLAN IDを使用するSiteすべてに適用されることになります。 適用したくない拠点にまで適用されるリスクがあるため、極力 対象を絞るほうが安全 でしょう。 Source 適用対象とする通信の「接続元」を指定します。 固定のIPアドレスやIPレンジ、VLAN、Network Interface等を指定可能です。 従来通りに個別のSiteで作成したVLAN/サブネットを対象とする場合は、 「Site Network Subnet」から選択することとなるでしょう。         Internet FirewallやWAN Firewallとは異なり、 ユーザ・ユーザグループでの指定はできない 点に注意が必要です。 Destination 適用対象とする通信の「接続先」を指定します。 指定方法は「Source」同様です。 Service/Port 対象とする通信を、HTTP等のプロトコル、または宛先ポートで絞ることが可能です。 後程作成する「LAN Firewall Rule」で指定する形としても問題ありません。 適用対象をより確実に絞り込みたい場合は、こちらで指定すると良いかもしれません。 NAT 行きの通信について、NATを適用して接続元IPアドレスを固定することが可能です。 Transport 適用対象を、LAN経由(PoPを通さない)またはWAN経由(PoPを通す)とするよう指定します。 基本的に、LAN Firewallを使う以上は「LAN」とすることが多いでしょう。 「WAN」を指定した場合、PoPを経由させることは継続しつつ WAN Firewallよりも優先度の高い制御としてLAN Firewallを適用することになります。 設定を作成し「Save」をクリックすれば、新しいNetwork Ruleが作成されたことを確認できます。 作成直後のPublishは厳禁 作成されたNetwork Ruleには、 デフォルトで「Block Any」が付与 されます。 つまり、Network Ruleを作成した直後にそのままPublishしてしまった場合、 条件を満たす経路の通信が全てBlockされる 事態が発生します。 必ず、次セクションの「Security Rule」を設定してからPublishしましょう。 Security Ruleの作成 Network Ruleで指定した対象の通信について、具体的な制御を行うのがSecurity Ruleです。 最低でも1つ「Allow」とするSecurity Ruleを設定しなければ、 Network Ruleで指定された対象の通信は 全て、暗黙のBlockの対象 とされてしまいます。 定義漏れが無いよう注意しましょう。 [Security] > [Firewall] > [LAN Firewall]にて、 [LAN Firewall]タブの「New > New LAN Firewall Rule」を選択すると新規作成が可能です。 項目名 役割 General ルールの名前や配置位置、適用する通信方向を定義します。 基本的に他のファイアウォールと同様ですが、 「どのNetwork Ruleに紐づけるか」を明示する必要がある という独自の特徴があります。 Source 適用対象とする通信の「接続元」を指定します。 固定のIPアドレスやIPレンジ、VLAN、Network Interface等を指定可能です。 従来通りに個別のSiteで作成したVLAN/サブネットを対象とする場合は、 「Site Network Subnet」から選択することとなるでしょう。         Internet FirewallやWAN Firewallとは異なり、 ユーザ・ユーザグループでの指定はできない 点に注意が必要です。 基本的にLAN Network Ruleの同名の項目とほぼ同じですが、 LAN Firewall Ruleの場合、ここでSiteを指定することも可能です。 Destination 適用対象とする通信の「接続先」を指定します。 指定方法は「Source」同様です。 App/Category 後述する「Layer 7設定」を有効化しているSiteに限り使用可能な項目 です。 ※有効化されていない状態で設定した場合、正常に動作しない場合があるとされています。         対象とするアプリケーションを指定できます。 例えば、「TeamViewerからのアクセスのみ許可」「Microsoft関連アプリの通信は許可」 といった従来のポート指定では困難であった設定が可能です。 Service/Port 対象とする通信を、HTTP等のプロトコル、または宛先ポートで絞ることが可能です。 例えば「HTTPアクセスは許可」「RDPやSSHは不許可」といったルールの作成に利用します。 Action 許可/不許可を設定します。 当該ルールにHitした場合の、イベント生成/メール通知の有無も指定可能です。 イベント生成については、トラブル時の確認のため原則有効とすることを推奨します。 設定を作成し「Save」をクリックすれば、新しいSecurity Ruleが作成されます。 Security Ruleは、対応するNetwork Ruleの配下に存在することが確認できるでしょう。 LAN Firewallは、以下の順序で動作します。 1.通信が、作成済の「LAN Network Rule」に該当するかどうかを上から順に確認 2. 該当した場合のみ 、当該Network Ruleに紐づけられた「LAN Firewall Rule」を 上から順に確認。いずれにも該当しなければ「Block Any」を適用 3.いずれの「LAN Network Rule」にも該当しなかった場合、 「Default send to cloud」が適用され、PoPへ転送。WAN Firewallを適用 このため、「LAN Firewall Rule」を本来と異なる「LAN Network Rule」へ 紐づけた場合、上記の「1.」の段階でスキップされてしまう可能性がございます。 適切な設定がなされたことを確認してから、右上の「Publish」を実行しましょう。 Layer 7機能の概要、有効化手順 今回のリニューアルにおいて「Next Gen LAN Firewall」として大きくアピールされているのが、 Layer 7に対応した制御機能です。 具体的には、従来の仕様と比べて下記のような違いがあります。 従来のLAN Firewall:IPアドレス、TCP/UDP、ポートで制御を行う Next Gen LAN Firewall:上記の制御に加え、 アプリケーション層の内容を参照した制御 も可能 例えば、SMBによるファイル共有を許可する上で、セキュリティに優れるSMBv3のみを許可する、 Windowsのアプリケーション全般を識別し、それだけを許可する、等の制御が可能となります。 本機能は、 デフォルトでは無効 となっています。有効にした場合にSocketで実施する処理が増え、 スループットが低下するリスクが存在するためです。 無効であっても、従来通りのLAN Firewallとしては正常に機能します。 有効化したい場合、[Security] > [Firewall] > [LAN Firewall]にて、 [LAN Firewall Settings]タブへ移動します。 上記画面で「New」を選択することで、Site単位での有効化設定が可能です。 通信量の多いSiteは対象外とする、テスト用の拠点でのみ有効にする、といった処置も行えます。   終わりに 従来よりInternet FirewallやWAN Firewallとは異なる操作方法であったLAN Firewallですが、 今回のリニューアルで大規模な変更が加えられました。 うまく使いこなせば、CatoのPoPへと向かう通信を減らし、 通信帯域を一定程度削減するといった効果を得られる場合もあります。 本記事も参考にしつつ、ぜひ活用を検討してください。
こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、Oracle 編と言うことで、Oracle 社が開発・販売されているリレーショナルデータベース管理システムを簡単に冗長化するための ARK の導入事例について、Linux 版をベースにご紹介していきます。 おさらい LifeKeeper の ARK について、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション(オープンソースソフトウェアや商用アプリケーション)を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式(GUI上で設定)で作業が可能となり、ARK には、アプリケーションを操作(起動・停止・監視・再起動)するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 Oracle ARK では、Oracle Listener と Oracle Database を、LifeKeeper の保護対象リソースとして登録し、保護する機能を提供します。 Oracle ARK は、汎用アプリケーション(Generic Application)リソースの導入とは違い、起動・停止・監視・再起動を行うためのスクリプトを明示的に指定することはなく、リソースの作成に必要な項目に対するパラメータをウィザード形式で入力または、選択することでリソースを作成することが出来ます。 Oracle ARK として Oracle Listener と Oracle Database の処理内容は以下の通りとなります。 Oracle Listener の処理 処理名 処理内容 起動処理 lsnrctl start コマンドによるリスナーの起動を実施 停止処理 lsnrctl stop コマンドによるリスナーの停止を実施 監視処理 lsnrctl status コマンドによるリスナーの状態を確認 再起動処理 lsnrctl start コマンドによるリスナーの起動を実施 Oracle Database の処理 処理名 処理内容 起動処理 startup コマンドによる Oracle の起動を実施 停止処理 shutdown コマンドによる Oracle の停止を実施 監視処理 ① ps コマンドによる Oracle の動作確認を実施 ② DB へ接続しコネクションの状態確認を実施 ③ 一時ファイルへ ORA エラーが出力されていないか確認を実施 再起動処理 ① shutdown abort による Oracle の強制終了を実施 ② startup コマンドによる Oracle の起動を実施し、失敗した場合、startup force コマンドで Oracle の起動を実施 Oracle ARK の構築例 それでは、実際に Oracle ARK の構築についてお話していきたいと思います。 Oracle ARK のパラメータ項目 Oracle ARK でリソースを作成する際は、事前に構成を決めておくことで、スムーズな作業が可能になります。 そこで Oracle Listener と Oracle Database のリソース固有のパラメータを一覧表にまとめてみましたので参考にしてみてください。 <Oracle Listener> 項目 設定値 内容 Listener Configuration File Path 「listener.ora」フルパス Oracle Listener の設定ファイルのフルパスを入力 Listener Name 【Listener名】 Oracle Listener 名を入力 Listener Executable 【プログラム実行パス】 Oracle Listener のプログラムの実行パスを入力 Listener Protection Level Full 又は Intermediate 又は Minimal Oracle Listener の保護レベルを選択 (Full, Intermediate, Minimal の3つから選択可能) ・Full:リスナーの起動、停止、監視、回復処理を実施(デフォルト) ・Intermediate:リスナーの起動、監視、回復処理を実施 ・Minimal:リスナーの起動、監視処理を実施 Listener Recovery Level Standard 又は Optional Listener のリカバリレベルを選択 (Standard,Optional の2つから選択可能) ・Standard:リスナーリソースの障害検出による、ローカルリカバリ と フェイルオーバーを有効にする ・Optional:リスナーリソースの障害検出による、ローカルリカバリを有効にし、フェイルオーバーを無効にする IP Adderss Name 【IPリソース名】 リソース階層の依存関係として保護される IP アドレスのリソース名を選択   <Oracle Database> 項目 設定値 内容 ORACLE_SID for Database 【Oracle-SID名】 ORACLE_SID を選択 Username 【Oracleユーザー名】 sysdba 権限のある、Oracle-SID にログインするユーザー名を入力 Password 【Oracleユーザーパスワード】 Oracle-SID にログインするユーザーのパスワードを入力 Select the Oracle Listener 【OracleListenerリソース名】 Oracleリスナーリソース名を選択 Oracle Database 関連リソースの作成 Linux 版の Oracle ARK では「Oracle Listener」と「Oracle Database」のリソースを作成することが可能です。 この2つのリソースを LifeKeeper の GUI によって作成する流れを例として紹介します。 注意 Oracle で使用する共有ディスクリソースと、 IP リソース、及び、別のリソース等、それぞれの依存関係がある状態で Oracle リソースを作成した場合、Oracle リソース作成時の自動による依存関係の作成が失敗する可能性があるため、必要に応じて依存関係を削除する必要があります。 以降の例では、共有ディスクリソースと IP リソースの依存関係がない状態で Oracle リソースの作成を実施しています。 <Oracle Listenerリソース作成> 処理内容 Oracle Listener リソース作成前のツリー構造 保護アプリケーションの選択(Oracle Database Listener) 稼働系ノードのSwitchbackタイプの選択 ※デフォルト:intelligent 稼働系ノードの選択 稼働系ノードのOracle Listener 設定ファイルのフルパスの入力 Oracle Listener 名の選択 稼働系ノードのOracle Listener プログラムの実行パスの入力 Listener リソースの保護レベルの選択 Listener リソースのリカバリレベルの選択 依存関係として保護される IP リソース名の選択 稼働系ノードの管理GUIに表示されるリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト:intelligent 稼働系ノードの優先順位の設定 ※デフォルト:1 待機系ノードの優先順位の設定 ※デフォルト:10 待機系ノードのリソース作成準備の確認結果 待機系ノードのOracle Listener 設定ファイルのフルパスの入力 待機系ノードのOracle Listener プログラムの実行パスの入力 待機系ノードの管理GUIに表示されるリソースタグ名の入力 待機系ノードのリソース作成結果 リソース作成後のツリー構造(Oracle Listener リソースと IP リソースの依存関係が自動で作成される)   <Oracle Databaseリソース作成> 処理内容 Oracle Database リソース作成前のツリー構造 保護アプリケーションの選択(Oracle Database) 稼働系ノードのSwitchbackタイプの選択 ※デフォルト:intelligent 稼働系ノードの選択 ORACLE_SID の選択 Oracle-SID のログインユーザー名の入力 Oracle-SID のログインユーザー名のパスワードの入力 Oracleリスナーリソース名の選択 稼働系ノードの管理GUIに表示されるリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト:intelligent 稼働系ノードの優先順位の設定 ※デフォルト:1 待機系ノードの優先順位の設定 ※デフォルト:10 待機系ノードのリソース作成準備の確認結果 待機系ノードの管理GUIに表示されるリソースタグ名の入力 待機系ノードのリソース作成結果 リソース作成後のツリー構造(Oracle Database リソースと共有ディスクリソース・Oracle Listener リソースの依存関係が自動で作成される) これで、LifeKeeper による Oracle Database 製品 のリソースが完成です。 あとは、必要に応じてリソース階層の依存関係を変更します。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、Linux 版の Oracle Database 製品のリソース作成について紹介してみました。 Oracle ARK は、汎用アプリケーション(Generic Application)リソースとは違い、起動・停止・監視・再起動を行うためのスクリプトを準備する必要がなく、リソースを作成することで意識することなく自動でスクリプトが導入されます。 LifeKeeper の機能として、リソース作成後、必要に応じて再起動処理やフェイルオーバー処理を無効化にすることも出来ます。システムの要件に合わせカスタマイズが可能になっています。 Oracle ARK を導入するための手順を纏めます。 ・Oracle Listener と Oracle Database のリソース固有のパラメータの設定値を検討する ・LifeKeeper GUI を用いて、Oracle Listener と Oracle Database のリソースを作成する LifeKeeper では Oracle Database 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 JP1/AJS3 ARK の導入事例に関しては以下のリンクからどうぞ! LifeKeeper ARK の導入事例を紹介<JP1/AJS3編> – TechHarmony 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
みなさん、こんにちは。 SCSK株式会社の津田です。 今回は前回に引き続きLifeKeeper運用での基本的操作をご紹介します。 LifeKeeperではGUIとコマンドでの操作が可能です。 本記事では コマンドでの操作 をご紹介させて頂きます。 前回のGUI編の記事と読み比べて頂くことで、コマンドでの操作内容や操作感の違いがよりイメージしやすいかと思います。 LifeKeeper基本運用操作(GUI編) 今回はLifeKeeper運用での基本的操作をご紹介します。LifeKeeperではGUIとコマンドでの操作が可能です。本記事ではGUIでの操作をご紹介させて頂きます。 blog.usize-tech.com 2025.07.15 はじめに コマンドによる操作の特徴 ・LifeKeeper GUIによる基本運用操作では、自サーバだけでなく対向サーバの情報取得や操作が可能でしたが、   コマンドによる操作は、基本的にコマンドを実行するサーバ自身に限定されており、対向サーバに対する情報取得や   直接的な操作はできません。 ・操作はTeraTerm等のターミナルやコマンドプロンプトから実行可能です。   (LifeKeeperコマンド格納先(デフォルト)  Linux:/opt/LifeKeeper/bin   Windows:C:\LK\Bin )   ここではターミナルからのコマンド実行を例にご紹介していきます。 GUI編の記事同様、以下LifeKeeper構成を例にコマンドライン基本操作を紹介していきます。 ステータス確認  /opt/LifeKeeper/bin/lcdstatus -e   でリソースのステータス確認ができます。 ※ステータス確認を行いたいサーバでコマンド実行が必要です。 ▼稼働系ステータス確認 ▼待機系ステータス確認   以下を参考に「STATE」項目でステータス情報の確認ができます。 GUIではアイコンからステータスが確認できましたが、CLIではアルファベット(略語)で表示されます。   リソース停止起動 全リソース停止 LifeKeeperで制御している全リソースの停止方法をご紹介します。 ※LifeKeeperのサービス自体は停止されません。 ※リソース停止を行いたいサーバでのコマンド実行が必要です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、   リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。 稼働系で /opt/LifeKeeper/bin/perform_action -t <最下位リソース> -a remove を実行すると稼働系で起動中の全リソースが停止します。 /opt/LifeKeeper/bin/lcdstatus -e で全リソース停止を確認できます。      リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。 そのため本構成でいうと「httpd」リソース単体停止、「httpd」と「ip-10.10.5.100」リソースだけ停止、という操作も可能ですが、リソースツリーの途中(「ip-10.10.5.100」リソース)だけ停止させることはできません。 (依存関係がなければ「ip-10.10.5.100」リソースのみの停止も可能。) 全リソース起動 LifeKeeperで制御している全リソースの起動方法をご紹介します。 ※リソース起動を行いたいサーバでのコマンド実行が必要です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、   リソース階層に基づき最下位のリソースから起動対象のリソースまでを順番に起動できます。←停止とは逆向きの動作になります! /opt/LifeKeeper/bin/perform_action -t <最上位リソース> -a restore -b  を実行すると全リソースが起動します。 /opt/LifeKeeper/bin/lcdstatus -e で全リソース起動を確認できます。   停止とは逆で、最下位のリソースから起動対象のリソースまで順番に起動されますので、 本構成でいうと「lbhc-12345」リソース単体起動、「lbhc-12345」と「ip-10.10.5.100」リソースだけ起動、という操作も可能ですが、リソースツリーの途中(「ip-10.10.5.100」リソース)だけ起動させることはできません。          (依存関係がなければ「ip-10.10.5.100」リソース単体停止も可能。)   LifeKeeper停止起動 LifeKeeperのサービス停止起動は、LifeKeeper GUI ではできない操作になります。 LifeKeeper停止 LifeKeeperのサービスを停止する方法をご紹介します。 ※LifeKeeperで制御している全リソースも停止します。フェールオーバは発生しません。 ※LifeKeeperのサービスを停止したいサーバでのコマンド実行が必要です。 /opt/LifeKeeper/bin/lkstop を実行するとLifeKeeperサービスが停止します。 LifeKeeperサービス確認コマンド /opt/LifeKeeper/bin/lktest を実行すると何も返らない状態(⇒LifeKeeper停止)となります。 LifeKeeper起動 LifeKeeperのサービスを起動する方法をご紹介します。 ※LifeKeeper停止時のリソース起動状態を保持します。 ※LifeKeeperのサービスを起動したいサーバでのコマンド実行が必要です。 /opt/LifeKeeper/bin/lkstart を実行するとLifeKeeperサービスが起動します。 LifeKeeperサービス確認コマンド /opt/LifeKeeper/bin/lktest を実行するとL ifeKeeper常駐プロセスが表示されます。   スイッチオーバ・スイッチバック スイッチオーバ 稼働系から待機系に起動中のリソースを手動で切り換える方法をご紹介します。 ※スイッチオーバ先(待機系)でのコマンド実行が必要です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、   稼働系の最上位リソースから最下位リソースの順番に停止、待機系の最下位リソースから最上位リソースの順番に起動することでスイッチオーバします。 スイッチオーバ先で /opt/LifeKeeper/bin/perform_action -t <最上位リソース> -a restore を実行すると全リソースが起動します。 /opt/LifeKeeper/bin/lcdstatus -e で確認すると、スイッチオーバにより待機系のリソースがアクティブ(ISP)状態になっています。 稼働系のリソースはスタンバイ(OSU)状態になります。 スイッチバック 待機系から稼働系に起動中のリソースを手動で切り戻す場合もスイッチオーバと同様の手順となります。 ※スイッチバック先(稼働系)でのコマンド実行が必要です。 スイッチバック先で /opt/LifeKeeper/bin/perform_action -t <最上位リソース> -a restore を実行すると全リソースが起動します。    /opt/LifeKeeper/bin/lcdstatus -e で確認すると、スイッチバックにより稼働系のリソースがアクティブ(ISP)状態になっています。 待機系のリソースはスタンバイ(OSU)状態になります。   さいごに 今回はコマンドによる基本的な運用操作についてご紹介しましたが、操作イメージを持って頂けましたでしょうか? LifeKeeper GUIは視覚的に分かりやすく直感的な操作が可能ですが、今回紹介したLifeKeeper停止起動のようにGUIではできない操作もあります。コマンドでは、こうした操作に加え、スクリプトやバッチ処理への組み込みが可能であり、運用の自動化や効率化にもつながります。GUIとコマンド、それぞれ状況に応じて使い分けて頂くことでより柔軟な運用が可能になるかと思います。 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで
SCSKの坂木です。 本記事では、Zabbixにおける脆弱性の対応方法について紹介いたします。   セキュリティパッチとバージョンアップ システムの脆弱性は、常にセキュリティ上の脅威です。脆弱性情報(CVE)が公開された際は、速やかな対応が不可欠であり、セキュリティパッチの適用など適切な対策を講じる必要があります。 Zabbix は セキュリティパッチを個別に提供する代わりに、バージョンアップによってバグや脆弱性へ対応 しています。 特にマイナーバージョンアップ(7.0.X の X の部分のみを変更)であれば、 メジャーバージョンを維持したまま脆弱性を解消 できます。 メジャーバージョンアップは影響範囲が大きく、ベンダーへの依頼が必要となるケースもありますが、マイナーバージョンアップは深刻な脆弱性対策として比較的容易に実施できます。 そこで、本ブログでは、 マイナーバージョンアップの手順を紹介 いたします。(RHEL系コマンドで実施してます)   Zabbixの脆弱性確認 お使いのZabbixのバージョンに脆弱性があるか、また、どのバージョンへアップデートすべきかについては、こちらのブログで詳しく解説しています。 Zabbixの脆弱性情報収集と確認方法について Zabbixの脆弱性情報の確認方法について生成AIで効率的に実施してみました。 blog.usize-tech.com 2024.08.27   Zabbixのマイナーバージョンアップ 本ブログでは、Zabbixサーバをバージョン7.0.8から7.0.16(ブログ作成時の最新バージョン)へマイナーアップデートします。 現在のZabbixサーバのバージョンを確認します。GUIで確認すると下の方にバージョンが記載されています。   CLIでは以下のコマンド等で確認できます。 # Zabbix_server -V # dnf  list installed | grep zabbix   最新バージョンに更新していきます。 # dnf upgrade zabbix-*   最新バージョンになっていることを確認します。 # dnf list installed | grep zabbix   GUIからも確認してみましょう。CLI、GUIどちらからもマイナーバージョンアップできていることを確認できました。   まとめ 最後までお読みいただき、ありがとうございます。 本記事では、Zabbixにおける脆弱性の対応方法を紹介しました。 最も重要なポイントは、 Zabbixのセキュリティは、パッチではなくバージョンアップで確保する ということです。この基本を押さえ、安全なZabbix運用を心がけていきましょう。   Zabbixをより詳しく知りたい方へ この度、SCSKが「Zabbix」を学ぶセミナーを開催します。 Zabbixの基本から最新機能までを学習できます。ぜひこの機会にお見逃しなく! 開催日時 2025年8月5日(火) 16:00~17:00 開催場所 オンラインセミナー(お申し込み後、受講用URLをご案内致します。) イベント詳細 Zabbix入門セミナー(夏) ~Zabbxiの基本とZabbixCloudについて~ オープンソースの監視ソフトウェア「Zabbix」を学ぶセミナーを開催します。このセミナーは、Zabbixを初めて学ぶ方や、監視システムの導入を検討している方に最適です。 基礎知識を習得し、実際の環境での監視設定を実践できるようになることを目... www.scsk.jp イベント申し込み Zabbixセミナー(8/5)登録 - 入力画面 form.scsk.jp   筆者の他のブログもよかったら見てやってください! 【Zabbix】トリガーアクションでスクリプトを実行する方法 本ブログではZabbixのトリガーアクションで障害対応を自動化する方法を解説します。 今回はトリガーアクションの中でもスクリプトの実行方法について説明します。 blog.usize-tech.com 2025.06.10 Zabbixで複雑なログ監視を実装する方法-count関数編- Zabbixのcount関数を使った複雑な条件のログ監視を行う方法をご紹介します。ログ監視で、5分間で5回”ERROR”という文字列が含まれるといった条件はパッと作成できますか?さらには、5分間で連続で5回”ERROR”という文字列が含まれるといったように、「連続で」という条件がつくとさらに頭を悩ませるのではないでしょうか。そこで今回は、このような条件式を作成できるcount関数を用いたログ監視について紹介していきます。 blog.usize-tech.com 2025.05.07
こんにちは、SCSK株式会社 櫻本です。 2025/6/11-13に幕張メッセで開催されたInterop Tokyo 2025に参加しました。 Interop Tokyoは、ネットワーク・AI・クラウド・セキュリティなどの最新技術や業界動向を体感できる、日本最大級のIT展示会です。 ※イベントの概要については他の方々が書いていますのでここでは割愛します。 このイベントには毎年参加しており、毎回ざっくりとした流行のキャッチアップのみで済ましていましたが、 今年は出展されている製品で担当している顧客の課題解決ができるかという観点で製品をチェックしてきました。 この投稿では顧客が抱える課題のうち、以下の課題に対して効果的な製品をご紹介いたします。 1.サーバの監視業務を行うオペレータが監視ツールからのアラートメッセージを目視で確認したうえで対応するため、多大な保守工数と人為的なミスの懸念を抱えている。 2.保守員がサーバにログインするためのアカウントを利用する際の手続き・事前作業によって発生する運用コストを削減したい。 1.WebSAM Automatic Message Call(NEC社) 【顧客の課題】 サーバの監視業務を行うオペレータが監視ツールからのアラートメッセージを目視で確認したうえで対応するため、多大な保守工数と人為的なミスの懸念を抱えている。 担当顧客では各監視ツールのメッセージをJP1に集約させ、オペレータがJP1のコンソールを確認したうえで手作業でアラートを通知する運用を実施しています。(下図を参照) この運用は24h/365dで行われており、オペレータ複数人での体制を敷いていることから高額な費用を必要としながら、目視でメッセージを確認していることからメッセージの見落とし・連絡先の誤りといったオペミスのリスクがあります。 【1-1.顧客の現状】 WebSAM Automatic Message Call(AMC)は前述の課題を解決する製品となっています。(Zabbixブースで紹介されていました) 機能としてはZabbixやJP1などから送信されるメッセージをAMCで収集し、AMCが事前に定義されたパターンマッチングを基に所定の担当者・通知手段で通知するというものです。 前述の担当顧客の現状で表現するなら、オペレータが実施する業務を全て自動化するものとなります。 オペレータの業務を自動化することでコスト減+オペミスのリスク減が実現できるため、前述の顧客課題を解消することができる製品と思いご紹介させていただきました。 【1-2.機能概要( クラウド型通報サービス WebSAM Automatic Message Call: WebSAM | NEC )】 2.Password Manager Pro(ManageEngine社) 【顧客の課題】 保守員がサーバにログインするためのアカウントを利用する際の手続き・事前作業によって発生する運用コストを削減したい。 担当顧客(前項と同じ顧客)では運用ベンダーがサーバにログインする際、大まかに以下の流れで手続きを行います。 下記手順の運用ではオペレータの負荷の高さや、サーバ利用時ログ取得に外部の録画ツールを必要といった課題があります。 ①.サーバの利用者がサーバの利用申請を起票 ②.システム管理者が承認 ③.オペレータがアカウントの申請を確認して手動でOSのアカウントロック解除を実施する ④.利用者がアンロックされたアカウントを使用して作業を実施する(利用者は録画ソフトを使用して作業証跡を記録する) ⑤.作業終了後にオペレータが手動でアカウントをロックする 【2-1.アカウント運用の現状】 上記の課題を解消するためのツールとして、Password Manager Proをご紹介いたします。 Password Manager Proはワークフロー機能とリモートアクセス機能を統合した特権ID管理ツールです。 申請・承認フローを通したアクセス制御の全てをWebアプリケーションで提供し、操作履歴の記録や画面の録画により監査対応も可能となります。 【2-2.PMP導入例】 前述の顧客のアカウント運用をツールで実現した場合、オペレータでの手動アンロック作業が不要となるため運用工数の削減が期待できます。 例えば、前述のアカウント運用手順で表現するなら、導入時は打消し線の箇所が不要となります。 ①.サーバの利用者がサーバの利用申請を起票 ②.システム管理者が承認 ③.オペレータがアカウントの申請を確認して手動でOSのアカウントロック解除を実施する ④.利用者がアンロックされたアカウントを使用して作業を実施する (利用者は録画ソフトを使用して作業証跡を記録する) ⑤.作業終了後にオペレータが手動でアカウントをロックする 特権ID管理ツールの類似製品はいくつかありますが、前述のアカウント運用の実施内容に対してはマッチした製品であるため、ご紹介させていただきました。 まとめ 今回のInteropではテーマが具体的であるが故に比較的狭い視野でブースを見ることになりましたがその分、各製品の説明やデモンストレーションでは製品の細かい仕様や実装例を知ることができました。 この記事を見ていただいた皆様も、具体的な課題を解決するという明確な目的をもって参加することで製品やサービスに対してより深堀することができると思いました。
皆さんこんにちは。UGです。 6月25日(水)、26日(木)に開催されたAWS Summit Japan 2025に出展しました。 【近日開催!】AWS Summit Japan 2025「AWSで、夢ある未来を共に創る。SCSK」ブースのご紹介! SCSKはいよいよ開催が迫る「AWS Summit Japan」に出展します。ブースでは「AWSで、夢ある未来を共に創る。SCSK」をテーマに独自ソリューションの4商材を展示、ミニシアターでは6つのAWS関連ソリューションから発表いたします。 blog.usize-tech.com 2025.06.02 今回、自分が所属するAWS内製化支援チームである『 テクニカルエスコート 』が、なんでも相談コーナーとしてブース出展を行いましたので、当日の様子をご紹介します! またテクニカルエスコートのメンバーである、貝塚社員がパートナーセッションに登壇されましたので、そちらについてもご紹介します! テクニカルエスコートとは?? 当日の様子をご紹介する前に、まずテクニカルエスコートってなんぞや?と思った方いらっしゃると思います。 「テクニカルエスコート」は、 お客様のチームに寄り添い、クラウド技術活用人材を育成する、AWS専門家による伴走型内製化支援サービス です。 お客様のプロジェクトにAWS技術者がアドバイザーとして参画し、技術的な指導や課題解決のアドバイスを提供することで、クラウド案件をスムーズに遂行できる体制を支援します。 ↓↓↓テクニカルエスコート公式ページ↓↓↓ AWS内製化支援サービス ー テクニカルエスコートサービス for AWS|サービス|企業のDX戦略を加速するハイブリッドクラウドソリューション SCSKの内製化支援サービス「テクニカルエスコートサービス」では、AWSの導入に関して課題に直面されているお客様に、上位認定資格を保有するAWSプロフェッショナルが参画し、AWS活用をサポートします。 www.scsk.jp ↑AWS Summit当日にお配りしていたブローシャー   なんでも相談コーナー では本題のブースの様子です。 ↑なんでも相談コーナー 前述の通りなんでも相談コーナーとして、本当にどんなことでもお聞きくださいというスタンスでブース出展を行っていました。 ぶっちゃけてしまうと本家AWSの方々が様々な相談窓口を設けているので、そんなに来ないのでは?というのが本音でした笑 ですが 嬉しいことに多くの方が足を運んでくださり、相談やテクニカルエスコートの説明を聞いてくださいました! 中にはAWSについて学びたいという熱意ある学生も来てくださりと、幅広い層への関心を実感しました。 相談内容としては、トレンドであるAIに関するものや、クラウドリフトが多かった印象です。 ↑ブースで相談にのるテクニカルエスコートメンバー(写真は兒玉エンジニア) 貝塚社員登壇『AI で振り込め詐欺を防止しろ! 四国銀行の 9 ヶ月間の挑戦』 26日(木)の13:00-14:00にてSCSKと四国銀行様との共同でのパートナーセッションがありました! このセッションでは、テクニカルエスコートのメンバーである貝塚社員と、四国銀行様 のご担当者様 がご登壇され、四国銀行様の取り組みの成果と内製化支援についてのお話をされました。 ↑当日のセッション風景。多くの方にご来場いただき満員御礼となりました! セッション後にはブースに足を運んでいただき、「感動しました!」とおっしゃってくださる方もいらっしゃいました。 非常にうれしいですね。 テクニカルエスコートメンバーがAWS パートナーネットワーク表彰制度にて選出 25日(水)の17:45~18:05にて表彰セッションが実施され、テクニカルエスコートからは7名が選出されました!! 表彰者 表彰名 TechHarmonyブログURL 広野 祐司 2025 Japan AWS Ambassadors 2025 Japan AWS Top Engineers (Services)  2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/hirono/ 寺内 康之 2025 Japan AWS Top Engineers (Services)  https://blog.usize-tech.com/author/y-terauchi/ 貝塚 広行 2025 Japan AWS Top Engineers (Networking)  2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/h-kaizuka/ 間世田 秀  2025 Japan AWS Jr. Champions https://blog.usize-tech.com/author/maseda/ 稲葉 航平 2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/k-inaba/ 尾身 優治 2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/omi/ 兒玉 純 2025 Japan All AWS Certifications Engineers https://blog.usize-tech.com/author/j-kodama/ ↑記念写真(左から「兒玉 純」「尾身 優治」「貝塚 広行」「間世田 秀」「広野 祐司」) 自分も今回初めて選出されまして嬉しい限りですが、来年はTop Engineersに選出されるように頑張っていきたいと思います! SCSK、AWS パートナーネットワーク表彰制度で過去最多の表彰者を輩出 ~高度な技術力と確かな実績で、「AWS に強いSCSK」を証明~ 最後に 弊社のセッションやブースにお越しいただいたみなさま、誠にありがとうございました! 自分は昨年初めてAWS Summitに参加し、当時はAWSを触れたばかりの初心者により雰囲気に圧倒されるだけでしたが、今年は圧倒されることなく楽しむことができたので、それなりに成長できているのかもしれません笑 また今年はブース出展でいろんな方とお話することができ、様々な刺激を得ることができました。 来年のAWS Summitも皆様楽しみましょ~!
みなさん、こんにちは。SCSK株式会社の津田です。 今回はLifeKeeper運用での基本的操作をご紹介します。 LifeKeeper導入後の運用操作のイメージを持っていただけたらと思います。 LifeKeeperではGUIとコマンドでの操作が可能です。 本記事では GUIでの操作 をご紹介させて頂きます。 はじめに GUI操作での特徴は何といっても直感的な操作、情報確認が可能な点です。 GUIはLifeKeeperをインストールした稼働系・待機系どちら側からも起動ができ、対向ノードの情報確認できたり操作が可能です。 ここでは以下LifeKeeper構成を例にGUI 基本操作を紹介していきます。 ※「LifeKeeper GUI」の画面を例に紹介しますが、Webブラウザを利用するLKWMCでのGUIも類似の画面構成となっておりますので同様に操作頂けます。 ステータス確認 GUIを起動するとまず最初に以下の画面が表示されます。 この画面だけでLifeKeeperのステータス確認が可能です。 ▼稼働系(lk01)からGUIを起動した場合の画面 ▼待機系(lk02)からGUIを起動した場合の画面 以下アイコン毎にステータス情報の確認ができます。 ▼サーバ状態の情報 ▼リソース状態の情報   リソース停止起動 全リソース停止 LifeKeeperで制御している全リソースの停止方法をご紹介します。 ※LifeKeeperのサービス自体は停止されません。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、   リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。   最下位リソースのActive上で右クリックし、「Out of Service」をクリックします。 以下の様な画面遷移を経て稼働系でアクティブとなっていた全リソースが停止状態になります。 全リソース停止後のGUI。       リソース階層に基づき最上位のリソースから停止対象のリソースまでが順番に停止されます。 そのため本構成でいうと「httpd」リソース単体停止、「httpd」と「ip-10.10.5.100」リソースだけ停止、という操作も可能ですが、リソースツリーの途中(「ip-10.10.5.100」リソース)だけ停止させることはできません。 (依存関係がなければ「ip-10.10.5.100」リソースのみの停止も可能。) ▼「httpd」リソースだけ停止 ▼「httpd」リソースと「ip-10.10.5.100」リソースだけ停止   全リソース起動 LifeKeeperで制御している全リソースの起動方法をご紹介します。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、 リソース階層に基づき最下位のリソースから起動対象のリソースまでを順番に起動できます。←停止とは逆向きの動作になります! リソース起動させたいサーバの最上位リソース(本構成でいう「httpd」リソース)を右クリックし、「In Service」をクリックします。 以下の様な画面遷移を経てリソースが全て起動します。 全リソース起動後のGUI。    停止とは逆で、最下位のリソースから起動対象のリソースまで順番に起動されますので、 本構成でいうと「lbhc-12345」リソース単体起動、「lbhc-12345」と「ip-10.10.5.100」リソースだけ起動という操作も可能です。 ただしリソースツリーの途中(「ip-10.10.5.100」リソース)だけ停止させることはできません。(依存関係がなければ「ip-10.10.5.100」リソース単体停止も可能。) スイッチオーバ・スイッチバック スイッチオーバ 稼働系から待機系に起動中のリソースを手動で切り換える方法をご紹介します。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 ※今回のLifeKeeperの構成のように依存関係(リソースツリー)を作成している場合、   稼働系の最上位リソースから最下位リソースの順番に停止、待機系の最下位リソースから最上位リソースの順番に起動することでスイッチオーバします。 待機系側の最上位リソース(「lbhc-12345」リソース)上で右クリックし、「In Service」をクリックします。 以下の様な画面遷移を経て待機系でリソースが全て起動します。   スイッチオーバ後のGUI。   スイッチバック 待機系から稼働系に起動中のリソースを手動で切り戻す場合もスイッチオーバと同様の手順となります。 ※稼働系から起動したGUI、待機系から起動したGUIどちらからでも操作可能です。 稼働系側の最上位リソース(「lbhc-12345」リソース)上で右クリックし、「In Service」をクリックします。 以下の様な画面遷移を経て稼働系でリソースが全て起動します。 スイッチバック後のGUI。 さいごに 今回はGUIでの基本的な運用操作をご紹介しましたが、いかがでしたでしょうか? LifeKeeper導入後のGUI操作イメージを持っていただけたら幸いです。 やはりGUIは視覚的にもわかりやすいため、GUIでの操作が圧倒的に多くなるかと思います。 しかしGUIでおおよその運用操作は可能であるものの、一部コマンドラインでしかできない操作もあります。 次回のコマンド編で一部紹介しますので、ぜひ見て頂ければと思います!   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで
こんにちは、石原です。 AWS上のデータベースのバージョンアップの際使用した 「Insight SQL Testing」 についてご紹介する内容の第二弾になります。 こちらはインサイトテクノロジー社が提供している製品になります。 Insight SQL Testing - 株式会社インサイトテクノロジー データベース移行及びバージョンアップ向けSQLテストソフトウェア。異種データベース間でSQLのテストができる唯一の製品。 www.insight-tec.com 本内容をご確認いただく前に前回の内容をまずご参照いただけると幸いです。 Insight SQL Testing を触ってみた(第一回) Insight SQL Testingを実際に触った内容を記事にしています。今後データベースのバージョンアップや移行を計画されており、それに伴う工数や懸念をお持ちの方々に是非知ってほしい製品になります。今回はMySQLを対象にして全体的な大まかな設定の流れや結果について概要レベルでまとめたものとなります。 blog.usize-tech.com 2025.04.03 前回は Insight SQL Testing に関して簡単に全体の設定の流れや結果についてお話をしました。 今回は「 Insight SQL Testing の製品導入」について取り扱います。 AWS Marketplace から SQL Testing Manager の Amazon マシンイメージを入手 Insight SQL Testingの導入用法は複数存在しますが、今回はAWSを利用している関係上、EC2上にInsight SQL Testing を構築する方法を紹介します。こちらに関しては、AMI(Amazonマシンイメージ:EC2の構築に必要な内容が入っているテンプレート)が提供されているため、比較的容易に導入が可能です。 注意点としては契約に応じた製品を選択する必要があります。 Insight SQL Testing 4マニュアル support.insight-tec.com 以下の内容は契約期間での請求「Insight SQL Testing Manager(BYOL)」を使用する場合を想定した内容となります。 早速、流れについての手順を説明していきます。 AWS Marketplace へ移動 AWSにログイン後、検索より「 AWS Marketplace 」と入力し、「サービス」→「AWS Marketplace」に移動します。 目的の製品を選択 ※契約に依存するため注意が必要 「製品を検出」を選択し、検索にて「Insight SQL Testing」を入力しInsight SQL Testingを絞り込みます。契約に依存する関係上、「Insight SQL Testing BYOL」などといったキーワードで絞り込んだ方が安全です。 私の環境では既にサブスクライブされていたため、説明を一部省略します。 サブスクライブの状況は「サブスクリプションの管理」より確認することができます。 インスタンスの起動 「新規インスタンスの起動」より、ソフトウェアの設定に遷移していきます。   新規インスタンスの設定 新規インスタンスの設定を行っていきます。 バージョン等の設定 以下の画像のように設定してください。 なお、今回解説した「ソフトウェアのバージョン」は、「4.2.0.0」ですが、基本的には最新バージョンを選択するようにしてください。「リージョン」は日本であれば「東京」か「大阪」のいずれかの選択になるかと思いますが、具体的な値は、「グローバル」をクリックすることで確認できます。入力が完了したら「EC2を介して起動を続ける」を押して次に進みます。 Launch an instance の設定 以下の様に、このページは少し縦に長い入力画面になります。 項目数が多いので特に重要なところだけを取り上げます。 キーペア(ログイン) この項目ではインスタンスの接続に必要なキーペアを作成します。 画面にも記載されているように設定は「必須」となります。 ここでは「新しいキーペアの作成」の一例を記載します。 キーペアのタイプは「RSA」または「ED25519」より選択可能です。 作成が完了すると、ローカルにキーファイルがダウンロードされます。 ネットワーク設定 ネットワークの設定は、既存のセキュリティグループを利用することもできます。 ただし、その場合はセキュリティグループにSSH(22)およびHTTP(7777)を追記しておく必要があります。 ストレージを設定 詳しくはシステム要件の確認が必要となりますが、監視対象のデータベース1インスタンスあたり、1カ月で約50GB程度のストレージが必要と想定されています。もちろん、ソースDB側の利用状況に依存して必要となるサイズは異なります。基本的には、データ量域として50GB, バックアップ領域に10GB程度設定しておくとよさそうです。 以下はデフォルトの設定を載せています。 上から以下のように対応しています。 /dev/sda1 → 32GB以上の指定が必要。未満の場合には以下のようにインスタンスの起動に失敗します。 /dev/sdb → データ領域 /dev/sdc → バックアップ領域 /dev/sdd → PostgresSQLのWALログ領域   インスタンスの起動 上記までの設定を行い、起動に成功すると以下の画面が表示されます。 起動後は以下の設定を行います。   まとめ 今回はEC2の作成方法ということで書いてみたものの、少し中身の薄い内容になってしまいました。 次回は実際のInsight SQL Testingの操作(特にInsight SQL Testingに対してMySQLのジェネラルログ(一般ログ)の読み取りについて)です。 実際にここの動作に一番検証に時間を要しました。 検証結果をまとめてご報告できればと思います。
みなさま、こんにちは! 最近笑いすぎてそろそろ腹筋が割れそうです。いとさんです。 先日目黒にてJapan AWS Top Engineers GameDay が開催されました。 社内のJapan AWS Top Engineersの方からご連絡いただき、こちらTop Engineerの方に同伴者が一人参加できるとのことで勇気を出して立候補しました。 私のスペック 名前 : いとさん ジョブ : サイト運営、セミナー運営、デザイン レベル : IT業界約1年 経験値 : AWSを触り始めて4ヶ月目 特技 : デザイン アイテム : PC んー…経験値もレベルも足りなさ過ぎているような気がしますが、とりあえずやってみようの精神で! AWS Top Engineersの方々の渦に飛び込んみました。 メンバーの皆さん [左から(アイレット株式会社)髙橋さん、私、(キンドリルジャパン株式会社)奈良さん、(ソニービズネットワークス株式会社)濱田さん] 上記の御三方、実は AWS Ambassadors… 私、とんでもなく凄いメンバーの方々と一緒になってしまいました 因みにチーム名は The Generators。 どこかアーティストみを感じるとってもいい名前ですね👍 GameDay概要 GameDayの詳細はネタバレ防止のため公開できませんが、4名1チームとなり技術的課題の解決に挑み、GenAIを使ってアプリケーションのバグや生成AIの組み込みを行うというものでした。 書くことが出来ないのが大変心苦しいのですが シナリオ概要の説明が面白く細かいところまでこだわっていて運営の皆様の努力を感じました。 作業内容 作業は私とリーダーの方を1人と換算し3人で大設問を分担して行っておりました。 やはりひよっこの私にできることはとても少なかったですね。 プロンプトエンジニアリング、Amazon Bedrockの概要、ガードレール等について、コーチングしていただきながら設問に対して回答していきました。私の担当した設問はAmazonQやBedrockを使用してAIと会話し解決するというプロンプトエンジニアリングが重要になってくる設問でした。 stepfunctionもサービスとしては知っていましたが初めて触り、どのように動作しているかを実際に確認することが出来ました。 他の設問を担当していたメンバーの皆さんの解決スピードは全体の中で 1桁台! (私は2桁…流石Ambassadorsの力強い…) お助けいただき、順調に進み残り1問となりました! 全体順位10位台、残り時間は1分…F5キーを連打、果たして完走できたのでしょうか… 結果はいかに… 終了~! 司会の方の合図とともに皆さん作業が終了いたしました。 解説の後ついに順位発表、果たして The Generators の結果は (;゚Д゚)(゚Д゚;(゚Д゚;)(;゚Д゚)…エッ? なななんと、 優勝 でした…滑り込みで回答が間に合っていたようです。(F5の力凄い…) チームメンバーの皆さん含めまさか優勝とは思っておらず喜びより驚きが大きかったです。(2,3位の方も例年参加されている方々のため) 今後に向けて … 参加して今後に活かしていきたいことがいくつかありました。 プロンプトエンジニアリングに関する知識の必要性 Bedrockに質問するにあたり漠然としたプロンプトでは、期待外れの出力しか生成できないことが多く、何度も試行錯誤を繰り返すことになります。プロンプトエンジニアリングを習得することで、 一度のプロンプトで目的の結果に近づける ことが可能になり、時間とリソースの無駄を省くことができると感じた。 幅広い知識の習得 今回GenAIに関するGameDayだったからなのかクラウドの知識とAIとの対話、コーディングの理解が必要。 原因解決にあたりサービスの理解に加え開発に関する多様な知識があるとスピーディーに原因究明、解決に進めるのかなと思った。 メンバーとのコミュニケーションの重要性 今回のメンバーの方はお互いに解決できないことに対し積極的に会話を行なっており明るく作業を進めているように感じた。制限時間の間ずっと各個人で黙々行うチームもあったのかと思いますが今回一緒に進めさせていただいたメンバーの方は会話を、雰囲気を大切にされていて実力もあると思いますが、そこがさらに優勝に繋がった要因なのかと思いました。今後の業務でもポジティブに雰囲気を大切にしていこうとさらに思わされました。   感想&賞品 問題によっては初学者(ひよっこ)でも解ける問題がある。 GameDayのテーマの学習を進めておくと少し楽になるかも…?と思いました! 初めてのGameDayは学びになることが多くとても楽しかったです。 新しい場所に飛び込むのは緊張すると思いますが玄人の皆さんはとても優しいです。 是非積極的に楽しんで飛び込んでいきましょう!! 優勝商品とシールをいただきました🎁かわいい 冷たい飲み物沢山飲みます🎵
SCSK 永見です。 Reserved Instance、コスト削減の話になると、よく出てきます。 これらを詳しく知ろうとして調べても、詳細な説明に終始して、そもそも何なの?というのがよくわからず困った記憶があります。 この記事は「Reserved Instance チョットワカル」私が、この記事の読者に「Reserved Instance 完全に理解した」状態へ導く記事となっています。 前提事項 この記事は、初めてReserved Instance(以下、RI と省略します)に触れる人向けに、分かりやすさに重きを置いて執筆しています。正確・詳細な情報は公式ドキュメントなどを参照にしてください。 また、料金はすべて例示の値です。正式な情報は料金表をご確認ください。 Amazon EC2 リザーブドインスタンス料金表 | AWS aws.amazon.com 今回はEC2のRIを例にとり、説明しています。 Reserved Instanceとは? カフェで使える割引券をイメージしてみましょう。 この割引券は、ドリンクの種類(コーヒー、カプチーノ、抹茶ラテ、etc…)、ドリンクのサイズ(S、M、L)、などを指定して購入します。 その割引券を使うことで、指定された条件と一致した種類・サイズのドリンクと引き換えることができます。 そして、普通に買うよりも割り引かれた金額でドリンクを購入することができます。 例えば、コーヒーSサイズ(以下、”コーヒー”と省略します)が1杯500円とし、この”コーヒー”用の割引券12枚つづりは4,800円で購入できる とします。 この割引券を使うことで、20%引きの400円で飲むことができます。 さて、割引券をRIに、”コーヒー”をインスタンスに置き換えてみましょう。 RIは、プラットフォーム(Linux、Windows、RedHat)、インスタンスタイプ(t3.large、r5.xlarge)などを指定して購入します。 購入されたRIは、指定された条件と一致したEC2インスタンスに対して、その料金として充当されます。 そして、オンデマンドで使うよりも割り引かれた金額でEC2インスタンスを利用することができます。 例えば、Linux、t3.largeのEC2インスタンスが、オンデマンドでは1時間あたり$0.1とし、このインスタンス相当のRI(1年間)は$560.64=$0.064/h×24時間×365日 で購入できる とします。 このRIの料金充当により、1時間あたり$0.064でEC2インスタンスを利用することができます。 じゃあたくさん買えばお得になるの? 安く使えるならたくさん割引券を買っておけば、お得になるんじゃないの?と思うかもしれませんが、そうはいきません。 この割引券は毎月1枚しか使えず、かつ1か月間の使用期限があります。 なので、毎月コンスタントに”コーヒー”を飲む人にとってはお得ですが、1か月で12杯飲むために使用することはできません。 同じくRIも、割引は一時間ごとに適用され、一時間のうちに使用されたEC2に対して割引が適用されます。 なので、24時間365日稼働するEC2がある場合にはお得ですが、一時的な開発で大量のEC2を使う という場合にはコストメリットは享受しづらいです。 どうやって使うの? コーヒーの割引券は購入の時に出すことで引き換えることができますが、RIは購入するだけで勝手に割引が適用されます。 また、コーヒーは”1杯”に対して割引が適用されますが、RIは対象のインスタンス”合計1台分”に対して割引が適用されます。 例えば、Linux、t3.largeのRIを1台分買っていて、かつLinux、t3.largeのEC2インスタンスが2台あった場合、30分間は2台ともRIによる割引料金で、のこり30分は2台ともオンデマンドの料金になります。 もっと安くするにはどうしたらいいの? もっとお得に、つまりもっと安く”コーヒー”を飲むにはどうしたらいいでしょうか。 主に3つ方法があります。 方法その1:有効期限が長いものを買う この割引券は12枚(12枚×1年分)綴りと36枚(12枚×3年分)綴りがあります。36枚入りのほうが、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 Reserved Instanceは、期間が1年間と3年間があります。3年間のほうが、より割引率が高くなります。 方法その2:先払いする この割引券には3種類の買い方があります。 1つは最初に全額払ってしまう方法、2つ目は半額払って半額ののこりを分割払いする方法、3つ目は毎月分割払いする方法。 最初に払う金額が大きいほど、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 RIは、支払い方法が全額前払い、一部前払い、前払いなしの3種類あります。 最初に払う金額が大きい、つまり全額前払い→一部前払い→前払いなし の順番で、より割引率が高くなります。 方法その3:交換できない割引券を買う この割引券には、”コーヒー”以外の割引券に交換できる種類とできない種類があります。交換できる割引券において、値段が違う場合は、差額を払うことで交換することができます。 交換できない割引券のほうが、より割引率が高く、安く”コーヒー”を買うことができます。 さて、割引券をReserved Instanceに、”コーヒー”をインスタンスに置き換えてみましょう。 Reserved Instanceは、提供クラスにはスタンダートとコンバーティブルがあります。スタンダードは他のReserved Instanceと交換できませんが、コンバーティブルであれば交換できます。 交換できないスタンダードのRIのほうが、より割引率が高くなります。 まとめ Reserved Instanceとはそもそも何なのか、について説明しました。 RIの活用はじめ、コストに関してお困りごとがあればぜひSCSKまでご相談ください! SCSKクラウドサービス(AWS)│SCSK株式会社|サービス|企業のDX戦略を加速するハイブリッドクラウドソリューション アマゾン ウェブ サービス(AWS)の最上位パートナーであり、多種多様な業界のシステム構築実績を持つSCSKが、最適なAWS導入をサポート。AWS活用によるお客様のITガバナンス強化とDX推進を強力に支援します。 www.scsk.jp
SCSK 永見です。 Reserved Instance、Savings Plans。 コスト削減の話になると、よく出てきます。 これらを詳しく知ろうとして調べても、詳細な説明に終始して、そもそも何なの?というのがよくわからず困った記憶があります。 この記事は「Savings Plans チョットワカル」私が、この記事の読者に「Savings Plans完全に理解した」状態へ導く記事となっています。 前提事項 この記事は、初めてSavings Plans(以下、SPsと省略します)に触れる人向けに、分かりやすさに重きを置いて執筆しています。正確・詳細な情報は公式ドキュメントなどを参照にしてください。 また、料金はすべて例示の値です。正式な情報は料金表をご確認ください。 Compute Savings Plans – アマゾン ウェブ サービス Savings Plans は柔軟な購入オプションです。1 年または 3 年の契約でさまざまな AWS Compute サービスに対する大幅な割引を提供します。Savings Plans には、Compute Savings Plans と... aws.amazon.com 今回はEC2のSPsを例にとり、説明しています。 Savings Plansとは? カフェで使えるプリペイドカードをイメージしてみましょう。 ドリンクの種類(全種類、コーヒー、カプチーノ、抹茶ラテ、etc…)、有効期限などを決めたうえで、金額を指定してチャージするようなプリペイドカードです。 このプリペイドカードで、指定したドリンクを購入することができます。 そして、普通に買うよりも割り引かれた金額でドリンクを購入することができます。 例えば、ホットコーヒー(以下、”コーヒー” と省略します)が1杯500円とします。 “コーヒー”用のプリペイドカードから支払うことで、20%引きの400円で飲めてしまいます。 さて、プリペイドカードをSavings Plansに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、適用するインスタンスの種類、期間などを決めたうえで、金額を指定します。これをコミットメントといい、「期間中、1時間当たり$〇〇分のリソースを使います!」と宣言するようなイメージです。 このコミットメント額は、指定された条件と一致するEC2インスタンスに対して、その料金として充当されます。 割引後の金額合計がコミット額に達する分まで、割引を適用することができます。 例えば、Linux、t3.largeのEC2インスタンスが、オンデマンドでは1時間あたり$0.1とし、t3系のSPsを$1.00/hのコミットメントを1年間分、つまり$365分購入した とします。 このSPsの料金充当により、1時間あたり$0.06でEC2インスタンスを利用することができます。 じゃあたくさんチャージすればお得になるの? 安く使えるならたくさんチャージしておけば、お得になるんじゃないの?と思うかもしれませんが、そうはいきません。 このプリペイドカードは毎月一定額しか使えず、かつ1か月間の使用期限があります。使い切れなかった分は失効してしまいます。 なので、毎月コンスタントに”コーヒー”を飲む人にとってはお得ですが、1か月で12杯飲むために使用することはできません。 同じくSPsも、割引は一時間ごとに適用され、一時間のうちに使用されたEC2に対して割引が適用されます。 なので、24時間365日稼働するEC2がある場合にはお得ですが、一時的な開発で大量のEC2を使う という場合にはコストメリットは享受しづらいです。 どうやって使うの? プリペイドカードは支払いの時に出すことで使うことができますが、SPsは購入するだけで勝手に割引が適用されます。 また、コーヒーは”1杯”に対して割引が適用されますが、SPsは対象のインスタンス”合計利用額”に対して割引が適用されます。 ちょっと難しいので、詳しく説明します。 例えば、このようなケースを想定してみましょう。 t3のEC2 Instance Savings Plans を$1.00/h分購入 t3.largeのEC2インスタンスが20台、1時間稼働。 このt3.largeインスタンスにおけるオンデマンド料金は$0.1/h、SPs料金は$0.06/h。削減率は40%=100%-$0.06÷$0.1 結論はこんなイメージになります。点線内がSPsによる充当で合計$1.00、点線外がオンデマンド価格となります。 細かく計算過程を追ってみましょう。 このケースの利用額は、全額オンデマンド料金と全額SPs料金の場合それぞれ算出すると、以下のようになります。 今回はSPsを$1.00分購入しているので、以下のように一部SPsによる充当、一部オンデマンドによる支払いに分けます。 $1.00のSPsによる充当額と、充当しきれなかった分のオンデマンド相当額の$0.33、計$1.33がかかります。 もっと安くするにはどうしたらいいの? もっとお得に、つまりもっと安く”コーヒー”を飲むにはどうしたらいいでしょうか。 3つ方法があります。 方法その1:有効期限が長いものを買う このプリペイドのチャージ方式は有効期限1年間(指定金額×12ヶ月分)と3年間(指定金額×36ヶ月分)があります。 3年間のほうが、より割引率が高く、安く”コーヒー”を買うことができます。 ※指定金額を大きくしても割引率は大きくなりません。 さて、プリペイドカードをSPsに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、期間が1年間(コミットメント額×24時間×365日)と3年間(コミットメント額×24時間×365日×3年間)があります。 3年間のほうが、より割引率が高くなります。 ※コミットメント額を大きくしても割引率は大きくなりません。 方法その2:先払いする このプリペイドカードには3種類のチャージ方法があります。 1つは最初に全額チャージしてしまう方法、2つ目は一部チャージしてのこりを毎月チャージする方法、3つ目は毎月チャージする方法。 最初にチャージする金額が大きいほど、より割引率が高く、安く”コーヒー”を買うことができます。 さて、プリペイドカードをSPsに、”コーヒー”をインスタンスに置き換えてみましょう。 SPsは、支払い方法が全額前払い、一部前払い、前払いなしの3種類あります。 最初に払う金額が大きい、つまり全額前払い→一部前払い→前払いなし の順番で、より割引率が高くなります。 方法その3:専用プリペイドカードを買う このプリペイドカードは、カフェの全商品に対して使える「なんでもプリペイドカード」と、特定の商品に対して使える「専用プリペイドカード」があります。 なんでもプリペイドカードよりも、専用プリペイドカードのほうが、より割引率が高く、安くコーヒーを買うことができます。 さて、割引券をSavings Plansに、コーヒーをインスタンスに置き換えてみましょう。 EC2に適用できるSPsには、Compute Savings PlansとEC2 Instance Savings Plansがあります。 Compute Savings Plansはあらゆる種類のEC2に適用されますが、EC2 Instance Savings Plansは購入時に指定したインスタンスファミリーのみに適用できます。 指定したインスタンスファミリーにしか適用できないSPsのほうが、割引率は高くなります まとめ SPsとはそもそも何なのか、について説明しました。 SPsの活用はじめ、コストに関してお困りごとがあればぜひSCSKまでご相談ください! SCSKクラウドサービス(AWS)│SCSK株式会社|サービス|企業のDX戦略を加速するハイブリッドクラウドソリューション アマゾン ウェブ サービス(AWS)の最上位パートナーであり、多種多様な業界のシステム構築実績を持つSCSKが、最適なAWS導入をサポート。AWS活用によるお客様のITガバナンス強化とDX推進を強力に支援します。 www.scsk.jp
こんにちは、ひるたんぬです。 最近は暑い日が続いていますね。私はこの時季になると冷房が欠かせないものとなっています。 世間では「春と秋がどんどん短くなっている」と言われており、私もそう思っていたのですが、具体的にどれだけ短くなっているのでしょうか? 調べてみると、そもそも春夏秋冬の絶対的な定義というものは存在しないようです。 気象学や天文学、伝統的な区切り方がそれぞれあるようですね。 こうなると、「私にとっての春」と「未来の人にとっての春」のイメージは大きく異なるものになりそうですね。 ひまわりは春の花、が常識になる日も…? ※ 参考… 国立天文台 | 暦Wiki「季節とは?」 さて、今回は標準ユーザーが管理者権限を持つユーザーに昇格した場合に、そのアクティビティをAmazon SNSを用いて通知する方法をご紹介します。 やりたいこと Windows OSにおいて管理者権限を持たないユーザーが、管理者権限を持つユーザーに昇格した場合に、他の管理者に通知したい場合を想定しています。今回のWindows OSはWorkSpaces上で稼働している想定ですが、WorkSpacesに限らず、どこでも通用するかなと思います。 やり方 ここからは、実際にどのように設定していくかをご紹介していきます。 事前準備 通知先のAmazon SNSトピック・サブスクリプションを作成します。 今回はメールでの通知を設定しています。 また、後述するスクリプトがメッセージを送信できるようにIAMユーザーとアクセスキーを作成します。 最小権限の原則から、当該トピックでのSNSメッセージ送信のみ許可されたIAMユーザーを新しく作成することを推奨します。 今回はこれら事前準備の手順は割愛します。詳細は公式ドキュメントなどをご参照ください。 Amazon SNS トピックを作成する - Amazon Simple Notification Service AWS SDKs を使用して Amazon SNS トピックを作成する包括的な手順について説明します。トピックタイプの選択、命名規則、暗号化の有効化、アクセス許可の設定の手順について詳しく説明します。 AWS Management Cons... docs.aws.amazon.com Amazon SNS トピックのサブスクリプションの作成 - Amazon Simple Notification Service を使用して Amazon SNS トピックにエンドポイントをサブスクライブする方法について説明します。トピック ARN の選択 AWS Management Console、エンドポイントタイプ (HTTP/HTTPS、E メール、Amaz... docs.aws.amazon.com AWS アカウント で IAM ユーザーを作成する - AWS Identity and Access Management AWS Identity and Access Management で IAM ユーザーと認証情報を作成するために使用されるプロセスの基本的な概要。 docs.aws.amazon.com IAM ユーザーの新しいアクセスキーを作成する - Amazon Keyspaces (Apache Cassandra 向け) AWS 認証情報を使用してプログラムによって Amazon Keyspaces に接続するために、IAM ユーザーまたはロールのアクセスキーを作成する方法を説明します。 docs.aws.amazon.com なにをトリガーにするか 今回の肝となるのは、「どのように管理者権限を持つユーザーに昇格したことを知るか」です。 調べてみると、これはWindows ログのイベントとしてログが記録されることが分かりました。 今回はこの中でも「セキュリティ」の中に記録されているイベントIDが4648のログに着目します。 このログは明示的な資格情報を使用したサインインを記録するもので、RUNASなどの昇格操作を実施した際に記録されるものです。 実際に昇格操作を実施したところ、確かにログが記録されることを確認したので、今回はこのイベントIDのログを利用することにします。 Amazon SNSでの通知スクリプト トリガーを受けての操作として、Amazon SNSを用いた通知を行います。今回はこの部分をPowerShellのスクリプトで作成しました。 今回は「admin」という名前を含むユーザーに昇格した場合に通知をするという内容にしています。 関数の引数はIAMの認証情報と、通知先のSNSトピックのARNが必須で必要です。適宜付与するようにしてください。 また、エラー処理などはすべて省いております。 function Get-AdminAlert {   param (       [Parameter(Mandatory = $true)]       [string]$AccessKey,         [Parameter(Mandatory = $true)]       [string]$SecretKey,             [Parameter(Mandatory = $true)]       [string]$TopicArn,                [Parameter(Mandatory = $false)]       [string]$Region = "ap-northeast-1"   )   # AWS CLI用の環境変数を設定   $env:AWS_ACCESS_KEY_ID = $AccessKey   $env:AWS_SECRET_ACCESS_KEY = $SecretKey   $env:AWS_DEFAULT_REGION = $Region     # イベントログから管理者に昇格しているログを抽出   $admin_name = "admin"   $now = Get-Date     # 発火時から30秒以内の該当イベントログを取得   $eventlog =  Get-EventLog -LogName Security -Newest 1 -EntryType SuccessAudit -InstanceId 4648 -Message *$admin_name* -After $now.Addseconds(-30)   if ($eventlog -eq $null) {       Write-Host "No relevant event logs found." -ForegroundColor Yellow       return $false   }     # Message内を処理するため、Jsonに変換後PowerShellオブジェクトに変換   $eventlog_json = $eventlog | ConvertTo-Json   $eventlog_object = ConvertFrom-Json $eventlog_json     # 昇格先アカウント名を抽出   $admin_account = $eventlog_object.ReplacementStrings[5]   if ($admin_account -eq $null) {       $admin_account = "Unknown"       Write-Host "No admin account found in the event log."   }     # イベント発生日時を抽出(UTC)   $eventtime = $eventlog_object.TimeGenerated   # イベント発生日時を日本時間に変換   $eventtime_jst = $eventtime.ToUniversalTime().AddHours(9)     # SNSメッセージの作成   $subject = "昇格操作が実行されました"   $snsMessage = "以下の昇格操作が実行されました。`n`n" +                 "昇格先アカウント: $admin_account`n" +                 "イベント発生日時: $eventtime_jst`n"     # Amazon SNSを使用して通知を送信 $messageId = (aws sns publish --topic-arn $TopicArn --subject $subject --message $snsMessage | ConvertFrom-Json).MessageId     finally {       # 環境変数をクリア       Remove-Item Env:\AWS_ACCESS_KEY_ID -ErrorAction SilentlyContinue       Remove-Item Env:\AWS_SECRET_ACCESS_KEY -ErrorAction SilentlyContinue       Remove-Item Env:\AWS_DEFAULT_REGION -ErrorAction SilentlyContinue   } } トリガーの設定 トリガーにしたいイベントと、実行したいスクリプトが完成したので、最後にトリガーを設定します。 ここでは、Windowsのタスクスケジューラを用います。 「全般」タブにおいて、タスク名には任意の名前を設定します。一方、セキュリティオプション内の「タスクの実行時に使うユーザー アカウント」ではSYSTEMユーザーを指定します。 「トリガー」タブでは、トリガーを設定します。先程決定したイベントをトリガーとして設定します。 「タスクの開始」を「イベント時」、「ログ」を「セキュリティ」、「ソース」を「Microsoft Windows security auditing.」、「イベントID」を「4648」とします。 次にトリガーが発火した後の操作を設定します。 「操作」タブから「操作」を「プログラムの開始」、「プログラム/スクリプト」を「PowerShell.exe」、「引数の追加」で「-NoProfile -ExecutionPolicy Bypass -File “ファイルパス”」と指定します。 動作確認 実際に昇格操作を実施してみます。すると… しっかりメールで通知がされました! 終わりに 今回はWindowsの標準機能とAWSの機能を組み合わせて管理者権限への昇格操作を通知する仕組みをご紹介しました。 タスクスケジューラのトリガーでは、トリガーのきっかけとなったイベントのログIDなどを知ることができないため、どのログによって発火したのかをPowerShellのスクリプトで知ることができません。 そのため、今回は30秒以内の最新の昇格操作を取得し送信するという対処法を取っています。 AWSのEventBridge的な感覚で触っていた私にとっては、この点は少し不便な仕様だな…と思った次第です。 余談 CloudWatch Agentをインストールして、セキュリティログをCloudWatch Logsに出力してゴニョゴニョ…の方がセンスあるかも?とも思いました。
はじめに 当記事は、 日常の運用業務(NW機器設定)の自動化 により、 運用コストの削減 および 運用品質の向上  を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと 試みた記事です。 Ansibleは、OSS版(AWX)+OSS版(Ansible)を使用しております。   PaloAltoの「Objects-サービス」の登録/変更/削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー:対象機器(ホスト)の接続先を設定。 ※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報:対象機器へのログイン情報(ユーザ名/パスワード)を設定。 ユーザ名は  変数:ansible_user   に保持される パスワードは 変数:ansible_password に保持される   Playbook作成(YAML) 使用モジュール paloaltonetworks.panos.panos_service_object  を使用。 ※参考ページ:https://galaxy.ansible.com/ui/repo/published/paloaltonetworks/panos/content/module/panos_address_object/   接続情報(provider)の設定 providerには、ip_address/username/password の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'   ← インベントリーのホストで設定   username: '{{ ansible_user }}'    ← 認証情報で設定   password: '{{ ansible_password }}'  ← 認証情報で設定   Objects-サービスの登録 接続情報とサービス情報を指定して登録(state: ‘present’)を行う。 - name: Add Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '10' source_port: '110' description: 'test_service001' tag: ['test'] state: 'present' register: wk_result 実行結果:対象のサービスが登録された。 ※Ansibleの実行結果(diff)を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの変更 ※登録のつづき 接続情報とサービス情報を指定して 登録されたサービスの変更( state: ‘replaced’ )を行う。  ※replacedの場合は、既存設定の置き換えとなる - name: Change Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '20' source_port: '120' description: 'test_service001' # tag: ['test'] state: 'replaced' register: wk_result 実行結果:登録時のtag指定ありのサービスが、Rreplaedによりtag指定なしのサービスに変更された。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n"   接続情報とサービス情報を指定して 登録されたサービスの変更( state: ‘merged’ )を行う。  ※mergedの場合は、既存設定の上書きとなる - name: Change Service2 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' protocol: 'tcp' destination_port: '30' source_port: '130' # description: 'test_service001' tag: ['test'] state: 'merged' register: wk_result 実行結果:上記変更時のtag指定なしのサービスが、mergedによりtag指定ありのサービスに変更された。また、サービス情報にdescriptionを指定しなくても、既存設定が維持されていることを確認。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの情報収集 ※変更のつづき 接続情報とサービスを指定して情報収集(state: ‘gathered’)を行う。 - name: Get Service Info paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' state: 'gathered' register: wk_result 実行結果:対象サービスの情報が取得できた。 ※Ansibleの実行結果(gathered_xml)を抜粋 "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n",   Objects-サービスの削除 ※変更のつづき 接続情報とサービスを指定して削除(state: ‘absent’)を行う。 - name: Delete Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: 'test_service001' state: 'absent' register: wk_result 実行結果:対象のサービスが削除された。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_service_object」を使用し、「Objects-サービス」の登録/変更/削除 および 情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より 設定変更の自動化 が活用できるようになると考える。 現状 設定情報がベタ書きで使い勝手が悪いので、今後 設定内容をINPUTする仕組みを試みたいと思います。 また、引続き 他にも様々なNW機器設定を自動化してみようと思います。
こんにちは。SCSKの青木です。 Interop Tokyo2025の2日目に参加してきました。 参加したセッションや見に行った展示について感想を書こうと思うので、気になるものがあればぜひ読んでください。 Interopとは 日本を問わず色々な企業が参加し製品紹介やセミナーを行っているインターネットテクノロジーのイベントになります。 以下は公式からの引用となります。 Interop Tokyoはインターネットテクノロジーのイベントです。 1994年の日本初開催以来、毎年国内外から約500の企業・団体が参加し、技術動向とビジネス活用のトレンドを、会場でのデモンストレーションやセミナーを通じてお伝えしてきました。国内のインターネットや技術革新の歴史と共に歩んできたこのInterop Tokyoをご覧いただくことで、インターネット分野のトレンドをいち早く体感いただくことができます。 引用) Interop Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 www.interop.jp   参加したセッション この製品チェック!~アワード審査員が今年の注目製品を解説~ 6/12(木)、6/13(金)の二日に分けて注目製品の発表がありました。 物理機器やラックの紹介が多く、クラウド案件を担当しているため、あまり考えたことはなかったですが、データセンターには、このようなネットワーク機器が数多く並んでいるのだと実感しました。 6/12(木)の解説された部門 ・セキュリティ ・デジタルメディア ・産業ネットワーク ・IoT/エッジコンピューティング ・ファシリティ 特に印象に残った製品:Cisco社「Cisco AI Defense」 普段はサーバやクライアントに対してセキュリティ製品を導入するのが一般的だと感じていましたが、日々利用しているAIに対して専用のセキュリティ製品を使用するという発想は思い浮かんだことがありませんでした。 また、AIを活用すること方法については考えたことはありますが、AIに対する攻撃について考えることがなかったのでAIに対する攻撃を知る良い機会となりました。 参考) アワード受賞企業一覧 Interop Tokyo 2025 「Interop Tokyo」は技術動向とビジネス活用のトレンドを会場でのデモンストレーションやセッションを通じてお伝えするインターネットテクノロジーイベントです。 interop.jp Cisco AI Defense Cisco AI Defense AI Defense は、AI の開発、展開、使用によってもたらされる安全性およびセキュリティのリスクを防ぐ、エンドツーエンドの AI セキュリティソリューションです。 www.cisco.com Chrome Enterpriseで実現する、AI時代の生産性とゼロトラスト 主な紹介機能 ・マルチOS対応のブラウザ制御 ・拡張機能のリスク監査と制御 ・悪意のあるサイトへのリアルタイム監査 ・セキュリティログの可視化・分析 管理方法の特徴 ・上記の機能は、ブラウザにログインすることでポリシーとして適用される。 ・ブラウザベースで一元管理できるため、業務をブラウザに集約することでデバイス側の設定が削減可能となる。 Chrome OS活用によるメリット ・Chrome OSを合わせて使用することにより、運用効率化、コスト削減、セキュリティ強化が実現できると紹介がありました。 感想 ・ブラウザに業務を集約することで、利用者のデバイス準備や作業の負担軽減が期待できるため、Microsoft製品によるOSやユーザ管理(AD活用)が多いですが、今後はAD不要でGoogleアカウントとChromeブラウザを活用したGoogle製品による運用に移行する企業も増えていくのではないかと感じました。 ・いただいた資料の情報ですが、2024年5月時点の情報によると、Chrome OSはおよそ15年のリリース期間で、マルウェア/ランサムウェア被害が「ゼロ」、ウイルス攻撃の成功報告も「ゼロ」となっています。非常に高いセキュリティ実績ですごいですね。 参考) Chrome OS ChromeOS - ビジネスに適した安全なクラウド ファーストの OS chromeos.google   展示ブース 各社のブースに訪問させていただいて特に印象に残ったブースを紹介いたします。 社内業務効率化AI KDDI株式会社様 KDDI社内プロジェクトにより、営業の生産性向上を目的として開発された生成AIツールについて紹介していただきました。 社内には膨大な資料が存在し、それらから必要な情報を探すことは時間がかかったり、似たような資料を参考に新規で提案資料等の資料を作成することに時間がかかったりしており、以下の機能を持たせた生成AIツールを作成し業務を効率化したとのことでした。 (情報収集については、社内の利用者のアンケートで74%情報収集時間を削減できたとのことです。) ▼生成AIツールの機能 ・資料の検索 ・資料の要約 ・社内の過去資料を基にドラフト資料を自動生成 ・資料のレビュー 資料の検索、ドラフト版の作成から資料のレビューまでの資料作成全体の効率化ができており、過去の資料というナレッジの蓄積をAIを活用しており、利用ができたらとても便利なサービスだと感じました。 参考) AIエージェント(上記記載の生成AIツールはA-BOSSとなります) AIエージェントとは?生成AIからの進化点や導入事例、注意点など解説 |お役立ち情報|中小企業・法人向け|KDDI株式会社 ビジネスを推進する新たなAIの活用法「AIエージェント」に関する記事です。AIエージェントの仕組みと、KDDIの実践事例をもとに、業務効率化・コスト削減のポイント、セキュリティやバイアス対策までをコンパクトに解説します。 biz.kddi.com オンプレミス エイム電子株式会社様 ロック機構がついた電源ケーブルを展示しておりました。 ロック機構がついているため、電源ケーブルの抜けの防止や作業中の誤った電源ケーブルの抜線が防げるとのことです。 実際に自分で引っ張って抜けないを体験できる展示もあり、引っ張ってみても全然抜けず、確かに抜け防止になるなといった感じでした。 データセンターでは細部のケーブルまで検討が必要になるのだなと驚きました。 番外編 山口県&萩市様 行政として山口県&萩市が参加しており、企業誘致を進めているとのことでした。 ITの技術の展示が多いなか他とは違った観点でおもしろい試みだなと思いました。 実際に山口県&萩市様のブースで紹介資料を見ると仕事がしやすそうな環境なので少しいいなと思ってしまいました。 観光案内をいただいたので旅行でぜひ行ってみたいですね。   おわりに 5、6年前にもInteropに行かせていただいたことがありますが、業務経験が浅くふわふわしたまま参加したため、色々な製品があるなとか、色々な会社があるなくらいの社会勉強みたいな記憶があります。 今回はトレンドがAIだからAIと何かみたいな組み合わせが多いなだったり、ブースで気になる技術について聞いてみたりと充実して回れたので自身の成長を感じることができました。
今回は、前回投稿した「OSパッチ適用を自動化させた後、結果をメールに通知させる方法」をAWS CDKで実装する方法をまとめました。   AWS Systems Manager の Patch Manager で OS パッチ適用を自動化してみた AWS Systems Manager でパッチ適用を自動化する方法をまとめてみました。 blog.usize-tech.com 2025.01.22 OSパッチ適用結果をメール通知してみた Amazon CloudWatch Logs に出力されたログから、指定した任意の文字列をトリガーに Amazon SNS 経由で適用結果をメールで通知します。 blog.usize-tech.com 2025.02.07 はじめに 前回の記事ではAWSマネジメントコンソールを使って手動でOSパッチ適用の自動化システムを構築しました。 今回は、同じシステムをAWS CDK(Cloud Development Kit)を使ってコード化し、Infrastructure as Code(IaC)として管理できるようにしていきます。   今回作成するリソース SNSトピック: メール通知用 IAMロール: SSM実行用とLambda実行用 パッチベースライン: Windows Server 2022用 メンテナンスウィンドウ: 毎月第1月曜日に実行 Lambda関数: パッチ結果解析とSNS送信 CloudWatchロググループ: パッチ実行ログ保存用 サブスクリプションフィルター: Lambda起動トリガー   AWS CDK ソースコード lib/patch-automation-stack.ts を、以下のように実装します。 最初に各コンポーネント毎に詳細を解説し、最後にソースコードをまとめて記載します。 また、CDKでは名前の自動設定やgrantメソッドなど便利な機能がありますが、実際の案件では様々なリソースに名前を設定する必要があったため名前を定義できるように実装をしています。   SNSトピックとメール通知設定   // パッチ通知用SNSトピックの作成   const patchtopic = new sns.Topic(this, 'PatchNotificationTopic', {     topicName: 'sns-patch-notification',     displayName: 'パッチ適用結果通知'     });   // SNSトピックに通知先メールアドレスを設定   patchtopic.addSubscription(     new subscriptions.EmailSubscription('your-email@example.com')        //実際のメールアドレスへ変更     ); ポイント: EmailSubscription で通知先メールアドレスを設定 実際のメールアドレスに変更する必要があります   IAMロールの設定   // SSM Run Command実行用のIAMロール   const ssmRunCommandRole = new iam.Role(this, 'SSMRunCommandRole', {     assumedBy: new iam.ServicePrincipal('ssm.amazonaws.com'), roleName: 'SSMRunCommandRole',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),       iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),     ],     description: 'Role for SSM Run Command execution'     });   // Lambda関数のIAMロール作成   const lambdaPatchRole = new iam.Role(this, 'LambdaPatchRole', { roleName: 'LambdaPatchRole',     assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),     description: 'Lambda execution role for patch notification',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')     ]   });   // Lambda関数にSNSの権限を付与   new iam.Policy(this, 'LambdaPatchSnsPolicy', {     policyName: 'LambdaPatchSnsPolicy',     roles: [lambdaPatchRole],     statements: [                                                                 new iam.PolicyStatement({         effect: iam.Effect.ALLOW,         actions: ['sns:Publish'],         resources: ['*']       })     ]     }); ポイント: SSMロール : メンテナンスウィンドウでのパッチ適用実行に必要な権限 AmazonSSMMaintenanceWindowRole : メンテナンスウィンドウ専用権限 AmazonSSMManagedInstanceCore : SSM基本通信権限 Lambdaロール : CloudWatch LogsアクセスとSNS発行権限 AWSLambdaBasicExecutionRole : Lambda基本実行権限 カスタムポリシーでSNS発行権限を追加   パッチベースラインの設定 new ssm.CfnPatchBaseline(this, 'WindowsPatchBaseline', { operatingSystem: 'WINDOWS', name: 'winsv-baseline', approvalRules: {   patchRules: [{     approveAfterDays: 0,                    // リリースから0日後に承認     complianceLevel: 'CRITICAL',            // コンプライアンスレベル:重要     enableNonSecurity: false,               // セキュリティパッチのみを対象     patchFilterGroup: {       patchFilters: [         {           key: 'PRODUCT',           values: ['WindowsServer2022']    // WindowsSrver2022で設定         },         {           key: 'CLASSIFICATION', // Windowsの更新プログラム分類           values: ['CriticalUpdates', 'SecurityUpdates'] // 重要な更新プログラム,セキュリティ更新プログラム         },         {           key: 'MSRC_SEVERITY', // Microsoftが定める重要度           values: ['Critical','Important'] // 致命的な問題を修正,重要な問題を修正         }       ]     }   }] }, patchGroups: ['winsv-patch-group'] // 対象パッチグループ }); ポイント: operatingSystem : 対象OS(WINDOWS、AMAZON_LINUX、UBUNTU等) approveAfterDays: 0 : リリース直後からパッチ適用可能(本番では7-30日を推奨) enableNonSecurity: false : セキュリティパッチのみに限定 フィルター条件 : PRODUCT : 対象Windows製品 CLASSIFICATION : パッチの分類 MSRC_SEVERITY : Microsoftが定める重要度   メンテナンスウィンドウの設定 const patchMaintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'PatchMaintenanceWindow', { name: 'monthly-patch-maintenance-window', schedule: 'cron(0 16 ? * MON#1 *)', duration: 2, cutoff: 0, allowUnassociatedTargets: false, scheduleTimezone: 'Asia/Tokyo' }); スケジュール設定は現在以下のように設定していますので、要件に応じて修正してください。 cron(0 16 ? * MON#1 *) : JST時間で第1月曜日16:00 duration: 2 : 2時間のメンテナンス枠 scheduleTimezone: 'Asia/Tokyo' : 日本時間で管理   パッチ適用対象の設定 const patchTarget = new ssm.CfnMaintenanceWindowTarget(this, 'PatchTarget', { windowId: patchMaintenanceWindow.ref, targets: [{   key: 'tag:PatchGroup',   values: ['winsv-patch-group'] }], resourceType: 'INSTANCE', ownerInformation: 'Patch管理対象インスタンス' }); ポイント: targets: でパッチ適用対象インスタンスを設定 事前にEC2インスタンスでタグの設定が必要 今回の場合必要なタグ設定 -  キー: `PatchGroup`  – 値: `winsv-patch-group`   RunCommandタスクの作成 // パッチ適用タスクの作成 const patchExecutionTask = new ssm.CfnMaintenanceWindowTask(this, 'PatchExecutionTask', { // 基本設定 windowId: patchMaintenanceWindow.ref,                          // メンテナンスウィンドウの参照 taskArn: 'AWS-RunPatchBaseline',                               // 実行するSSMドキュメント taskType: 'RUN_COMMAND',                                       // タスクタイプ:RunCommand name: 'SecurityPatchInstallation',                             // タスク名 description: 'セキュリティパッチの自動インストールと再起動',      // タスクの説明 priority: 1,                                                   // タスクの優先度(1が最高) maxConcurrency: '1',                                           // 同時実行数:1台ずつ順次実行 maxErrors: '0',                                                // エラー許容数:0(1台でもエラーなら停止) serviceRoleArn: ssmRunCommandRole.roleArn,                    // SSM実行用IAMロール targets: [{   key: 'WindowTargetIds',                                      // ターゲット指定方法   values: [patchTarget.ref]                                    // 事前に定義したターゲットを参照 }], taskInvocationParameters: {   maintenanceWindowRunCommandParameters: {     documentVersion: '$LATEST',                                // 最新バージョンのドキュメントを使用     parameters: {       Operation: ['Install'],                                  // 操作:パッチのインストール実行       RebootOption: ['RebootIfNeeded'],                       // 必要に応じて自動再起動       SnapshotId: ['{{WINDOW_EXECUTION_ID}}']                 // 実行IDをスナップショットIDとして記録     },     timeoutSeconds: 600,                                     // タイムアウト(必要に応じて修正)     cloudWatchOutputConfig: {       cloudWatchLogGroupName: 'aws-ssm-patch-execution-logs', // CloudWatch Logsグループ名       cloudWatchOutputEnabled: true                           // CloudWatch Logs出力を有効化     }   } } }); ポイント: taskArn : ‘AWS-RunPatchBaseline’でパッチ適用を実行 priority : 1が最高優先度 maxConcurrency : 同時実行数制御(’1’=順次、’50%’=半数同時) maxErrors : エラー許容数(’0’=1台でもエラーなら停止) 重要パラメータ : Operation: ['Install'] : パッチを実際にインストール RebootOption: ['RebootIfNeeded'] : 必要時のみ再起動 SnapshotId : 実行履歴の追跡用   Lambda関数作成   // Lambda関数作成   const patchNotificationLambda = new lambda.Function(this, 'PatchNotificationFunction', {     functionName: 'lmd-patch-send-sns',                      // 関数名     runtime: lambda.Runtime.PYTHON_3_13,                     // 実行環境:Python 3.13     handler: 'index.lambda_handler',                         // エントリーポイント     code: lambda.Code.fromAsset(                             // ソースコードの場所       path.join(__dirname, 'lambda')     ),     role: lambdaPatchRole,                                   // Lambda実行時IAMロール     environment: {                                           // 環境変数       SNS_TOPIC_ARN: patchtopic.topicArn,                    // SNSトピックのARN       ALARM_SUBJECT: 'パッチ適用結果通知'                     // メールの件名     },     timeout: cdk.Duration.seconds(600),                      // 実行タイムアウト     memorySize: 128,                                         // メモリ割り当て(MB)   }); ポイント: runtime : Python 3.13 code :  lib/lambda ディレクトリからコード読み込み environment : SNSトピックARNとメール件名を環境変数で設定 timeout : 600秒 memorySize : 128MB   関数作成 import logging import json import base64 import gzip import boto3 import os logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context):   # CloudWatchLogsからのデータはbase64エンコードされているのでデコード   decoded_data = base64.b64decode(event['awslogs']['data'])   # バイナリに圧縮されているため展開   json_data = json.loads(gzip.decompress(decoded_data))   logger.info("EVENT: " + json.dumps(json_data))   # ログデータ取得   log = json_data['logEvents'][0]['message']   instanceid_position = log.find('PatchGroup')   instanceidtmp = log[:instanceid_position]   instanceid = instanceidtmp.replace('Patch Summary for ','')   print(instanceid)   result_position = log.find('Results')   result = log[result_position:]   print(result)   patchGroup_start = log.find('PatchGroup')   patchGroup_end = log.find('BaselineId')   patchGrouptmp = log[patchGroup_start:patchGroup_end]   patchGroup = patchGrouptmp.replace('PatchGroup          : ','')   print(patchGroup)     messagetmp = """ パッチ適用結果を通知します。 対象インスタンス・適用結果は下記となります。 〇対象インスタンス{0} 〇パッチグループ {1} 〇適用結果 {2}   """   message = messagetmp.format(instanceid,patchGroup,result)   print(message)   try:       sns = boto3.client('sns')       #SNS Publish       publishResponse = sns.publish(       TopicArn = os.environ['SNS_TOPIC_ARN'],       Message = message,       Subject = os.environ['ALARM_SUBJECT']       )   except Exception as e:         print(e) ポイント: lib/lambda/index.py にPythonコードを配置します   ロググループ設定   // パッチログ用のCloudWatchロググループ作成   const patchloggroup = new logs.LogGroup(this, 'PatchLogGroup', {       logGroupName: 'aws-ssm-patch-execution-logs', // パッチ適用ロググループ       retention: logs.RetentionDays.ONE_YEAR,       // 保持期間: 1年間       removalPolicy: cdk.RemovalPolicy.RETAIN       // スタック削除時に削除されない         });   new logs.SubscriptionFilter(this, 'PatchSummarySubscription', {     // サブスクリプションフィルターの設定(Lambda関数の起動トリガー)       logGroup: patchloggroup,                                         // 監視対象のロググループ       destination: new destinations.LambdaDestination(patchNotificationLambda),  // 送信先       filterPattern: logs.FilterPattern.literal('Patch Summary'),       // フィルター条件       filterName: 'PatchNotification'                                   // フィルター名     }); } ポイント: logGroupName: はRunCommandタスクの作成で指定したロググループ名と合わせる 保管期間は要件に合わせて修正する 今回実装したスタックファイルまとめ import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as ssm from 'aws-cdk-lib/aws-ssm'; import * as lambda from 'aws-cdk-lib/aws-lambda'; import * as logs from 'aws-cdk-lib/aws-logs'; import * as iam from 'aws-cdk-lib/aws-iam'; import * as sns from 'aws-cdk-lib/aws-sns'; import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions'; import * as path from 'path'; import * as destinations from 'aws-cdk-lib/aws-logs-destinations'; export class PatchAutomationStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) {     super(scope, id, props);   // パッチ通知用SNSトピックの作成   const patchtopic = new sns.Topic(this, 'PatchNotificationTopic', {     topicName: 'sns-patch-notification',     displayName: 'パッチ適用結果通知'     });   // SNSトピックに通知先メールアドレスを設定   patchtopic.addSubscription(     new subscriptions.EmailSubscription('your-email@example.com') // ここを実際のメールアドレスに変更     );   // SSM Run Command実行用のIAMロール   const ssmRunCommandRole = new iam.Role(this, 'SSMRunCommandRole', { roleName: 'SSMRunCommandRole',     assumedBy: new iam.ServicePrincipal('ssm.amazonaws.com'),     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),       iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),     ],     description: 'Role for SSM Run Command execution'     });   // Lambda関数のIAMロール作成   const lambdaPatchRole = new iam.Role(this, 'LambdaPatchRole', { roleName: 'LambdaPatchRole',     assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),     description: 'Lambda execution role for patch notification',     managedPolicies: [       iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')     ]     });   // Lambda関数にSNSの権限を付与   new iam.Policy(this, 'LambdaPatchSnsPolicy', {     policyName: 'LambdaPatchSnsPolicy',     roles: [lambdaPatchRole],     statements: [       new iam.PolicyStatement({         effect: iam.Effect.ALLOW,         actions: ['sns:Publish'],         resources: ['*']       })     ]     });   // パッチベースラインの作成   new ssm.CfnPatchBaseline(this, 'WindowsPatchBaseline', {     operatingSystem: 'WINDOWS',     name: 'winsv-baseline',     approvalRules: {       patchRules: [{         approveAfterDays: 0,                    // リリースから0日後に承認         complianceLevel: 'CRITICAL',            // コンプライアンスレベル:重要         enableNonSecurity: false,               // セキュリティパッチのみを対象         patchFilterGroup: {           patchFilters: [             {               key: 'PRODUCT',               values: ['WindowsServer2022']     // WindowsServer2022で設定             },             {               key: 'CLASSIFICATION',               values: ['CriticalUpdates', 'SecurityUpdates']             },             {               key: 'MSRC_SEVERITY',               values: ['Critical', 'Important']             }           ]         }       }]     },     patchGroups: ['winsv-patch-group']     });   // メンテナンスウィンドウの作成   const patchMaintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'PatchMaintenanceWindow', {     name: 'monthly-patch-maintenance-window',     schedule: 'cron(0 16 ? * MON#1 *)',         // 毎月第1月曜日 JST 16:00     duration: 2,                                // 実行可能時間:2時間     cutoff: 0,                                  // 新規タスク開始の締切時間     allowUnassociatedTargets: false,            // 関連付けされたターゲットのみ実行     scheduleTimezone: 'Asia/Tokyo'              // スケジュールのタイムゾーン     });   // パッチ適用対象の設定   const patchTarget = new ssm.CfnMaintenanceWindowTarget(this, 'PatchTarget', {     windowId: patchMaintenanceWindow.ref,       // メンテナンスウィンドウの参照     targets: [{       key: 'tag:PatchGroup',                    // タグによる対象選択       values: ['winsv-patch-group']             // 対象とするタグ値     }],     resourceType: 'INSTANCE',                   // 対象リソース種別:EC2インスタンス     ownerInformation: 'Patch管理対象インスタンス' // 管理用メモ     });   // パッチ適用タスクの作成   const patchExecutionTask = new ssm.CfnMaintenanceWindowTask(this, 'PatchExecutionTask', {     // 基本設定     windowId: patchMaintenanceWindow.ref,                          // メンテナンスウィンドウの参照     taskArn: 'AWS-RunPatchBaseline',                               // 実行するSSMドキュメント     taskType: 'RUN_COMMAND',                                       // タスクタイプ:RunCommand     name: 'SecurityPatchInstallation',                             // タスク名     description: 'セキュリティパッチの自動インストールと再起動',       // タスクの説明     priority: 1,                                                   // タスクの優先度(1が最高)     maxConcurrency: '1',                                           // 同時実行数:1台ずつ順次実行     maxErrors: '0',                                                // エラー許容数:0(1台でもエラーなら停止)     serviceRoleArn: ssmRunCommandRole.roleArn,                   // SSM実行用IAMロール     targets: [{       key: 'WindowTargetIds',                                      // ターゲット指定方法       values: [patchTarget.ref]                                    // 事前に定義したターゲットを参照     }],     taskInvocationParameters: {       maintenanceWindowRunCommandParameters: {         documentVersion: '$LATEST',                                // 最新バージョンのドキュメントを使用         parameters: {           Operation: ['Install'],                                  // 操作:パッチのインストール実行           RebootOption: ['RebootIfNeeded'],                       // 必要に応じて自動再起動           SnapshotId: ['{{WINDOW_EXECUTION_ID}}']                 // 実行IDをスナップショットIDとして記録         },         timeoutSeconds: 600,                                       // タイムアウト(必要に応じて修正)         cloudWatchOutputConfig: {           cloudWatchLogGroupName: 'aws-ssm-patch-execution-logs', // CloudWatch Logsグループ名           cloudWatchOutputEnabled: true                           // CloudWatch Logs出力を有効化         }       }     }     });   // Lambda関数作成   const patchNotificationLambda = new lambda.Function(this, 'PatchNotificationFunction', {     functionName: 'lmd-patch-send-sns',                       // 関数名     runtime: lambda.Runtime.PYTHON_3_13,                      // 実行環境:Python 3.13     handler: 'index.lambda_handler',                         // エントリーポイント     code: lambda.Code.fromAsset(                             // ソースコードの場所       path.join(__dirname, 'lambda')     ),     role: lambdaPatchRole,                                   // Lambda実行時IAMロール     environment: {                                           // 環境変数       SNS_TOPIC_ARN: patchtopic.topicArn,                     // SNSトピックのARN       ALARM_SUBJECT: 'パッチ適用結果通知'                       // メールの件名     },     timeout: cdk.Duration.seconds(600),                       // 実行タイムアウト     memorySize: 128,                                         // メモリ割り当て(MB)     description: 'パッチ適用結果を解析してSNS通知を送信する関数'  // 関数の説明   });   // パッチログ用のCloudWatchロググループ作成   const patchloggroup = new logs.LogGroup(this, 'PatchLogGroup', {     logGroupName: 'aws-ssm-patch-execution-logs',           // パッチ適用ロググループ     retention: logs.RetentionDays.ONE_YEAR,                 // 保持期間: 1年間     removalPolicy: cdk.RemovalPolicy.RETAIIN                 // スタック削除時に削除されない     });   // サブスクリプションフィルターの設定(Lambda関数の起動トリガー)   new logs.SubscriptionFilter(this, 'PatchSummarySubscription', {     logGroup: patchloggroup,                                         // 監視対象のロググループ     destination: new destinations.LambdaDestination(patchNotificationLambda),   // 送信先     filterPattern: logs.FilterPattern.literal('Patch Summary'),       // フィルター条件     filterName: 'PatchNotification'                                   // フィルター名   }); } }   まとめ 今回は、パッチ自動適用からメール通知までをAWS CDKでモジュール化してみました。 皆さんのお役に立てば幸いです。
こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.4がリリースされました。今回はicmppingretryについて検証したいと思います。 7.4の新機能につきましては、公式HPに記載がございます。 What's new in Zabbix 7.4 Create new resource discovery workflows, visualize your data in new ways, enjoy the improved user experience and much mo... www.zabbix.com Zabbix7.4はポイントリリースのため、サポート期間が短くなっています。 本番利用する場合は8.0LTSがリリースされるまでお待ちいただく事をお勧めします。 icmppingretryとは 公式HPでは以下の記載があります。 英語:A new icmppingretry simple check has been added to monitor host responses to ICMP ping with the ability to modify retries 翻訳:ICMP pingに対するホストの応答を監視し、再試行回数を変更するための新しいicmppingretryシンプルチェックが追加されました。 Ping監視で1回失敗した場合、間隔を狭くしてリトライする事ができるようです。 他の有償製品ではリトライをすることができるようで、問い合わせを多く頂いておりました機能になります。   アイテム作成 icmppingretryはアイテムキーのため、通常のPing監視で利用するicmppingとは別アイテムにする必要があります。 今までのicmppingキーにはない「retries」「backoff」が新しく設定できるようになっております。 逆に「interval」「packets」がなくなっております。細かいPingのオプションは指定できないようですね。 「reties」が 再試行回数 となっており、「backoff」で 再試行間隔の係数 を指定できるようです。 公式マニュアル – icmppingretry icmppingretry[<target>,<retries>,<backoff>,<size>,<timeout>,<options>] The host accessibility by ICMP ping with retries. Return value:  0  – ICMP ping fails;  1  – ICMP ping successful. Parameters: target  – the host IP or DNS name; retries  – the number of times an attempt at pinging a target will be made, not including the first try (0 or greater; default 1); backoff  – the number by which the wait time is multiplied on each successive request (1.0-5.0 range; default 1.0); size  – the packet size in bytes; timeout  – the timeout in milliseconds; options  – used for allowing redirect: if empty (default value), redirected responses are treated as target host down; if set to  allow_redirect , redirected responses are treated as target host up. 今回は検証用にicmppingretryとicmppingのアイテムを作成して比較しようと思います。 名前 Ping監視(icmpping) Ping監視(icmppingretry) タイプ シンプルチェック シンプルチェック アイテムキー icmpping[,3,2000,64,3000] icmppingretry[,3,3,256,500] 監視間隔 60s 60s   icmpping[,3,2000,64,3000]の動作について まずは、以前からあるicmmpingキーについて動作を確認していきます。 正常時 1回の監視で2秒間隔で3回パケットを送信します。1分間隔で繰り返します。 20:54:23.056236 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 0, length 72 20:54:25.056876 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 1, length 72 20:54:27.058276 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3048, seq 2, length 72 20:55:23.068729 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 0, length 72 20:55:25.070759 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 1, length 72 20:55:27.070773 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3055, seq 2, length 72 異常時 監視対象(192.168.1.1)をダウンさせてみます。 Zabbixから送信するパケットは正常時と変わらないことを確認します。 21:00:23.131611 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 0, length 72 21:00:25.133447 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 1, length 72 21:00:27.131777 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3112, seq 2, length 72 21:01:23.142971 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 0, length 72 21:01:25.143041 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 1, length 72 21:01:27.143408 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3134, seq 2, length 72 icmppingretry[,3,3,256,500]の動作について 次に新機能のicmppingretryについて確認いたします。 オプションは再試行回数3回、再試行間隔の係数は3、タイムアウト0.5秒になります。 正常時 1回の監視で1回だけICMPパケットを送信します。1分間隔で繰り返します。 icmppingキーでは細かく、回数や間隔を指定できていましたが、正常時は1回になるようです。 21:04:23.175696 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3166, seq 0, length 72 21:05:23.185637 IP ip-192-168-1-1.ap-northeast-1.compute.internal > ip-192-168-1-1.ap-northeast-1.compute.internal: ICMP echo request, id 3174, seq 0, length 72 異常時 監視対象をダウンさせてみると以下のパケットになります。 20:30:40.044485 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 0, length 264 20:30:40.545097 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 1, length 264 20:30:42.046686 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 2, length 264 20:30:46.547698 IP ip-10-0-2-117.ap-northeast-1.compute.internal > ip-10-0-2-194.ap-northeast-1.compute.internal: ICMP echo request, id 2428, seq 3, length 264 再試行回数:3回 通常監視が「20:30:40.044485」に行われ、その後3回、「20:30:40.545097」「20:30:42.046686」「20:30:46.547698」と再試行を行っています。再試行の際は、idが同じ「2428」でseqが連番となっています。   再試行間隔の係数:3 再試行の間隔は以下の通りになります。 再試行1回目:0.5秒(20:30:40.0 – 20:30:40.5) 再試行2回目:1.5秒(20:30:40.5 – 20:30:42.0) 再試行3回目:4.5秒(20:30:42.0 – 20:30:46.5) 再試行の回数が増えるごとに、間隔が長くなっていることがわかるかと思います。 再試行1回目の0.5秒は、icmppingretryキーの引数で指定したタイムアウトの0.5秒になります。 再試行2回目の1.5秒は、1回目の間隔(0.5)×再試行間隔の係数(3)の1.5秒になります。 再試行3回目の4.5秒は、2回目の間隔(1.5)×再試行間隔の係数(3)の4.5秒になります。 まとめ icmppingretryを使用することで、Ping疎通がNGの場合のみ、再試行することがZabbixでも実現できました。 ZabbixのPing監視の幅が広がったかと思います。  Zabbix is great! ※検証結果が間違っておりましたら、お知らせください SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント: www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ https://x.com/SCSK_Zabbix x.com  
こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、日立製作所から提供されているジョブ管理製品である JP1/AJS3 を簡単に冗長化するための ARK の導入事例をご紹介していきます。 おさらい LifeKeeper の ARK について、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション(オープンソースソフトウェアや商用アプリケーション)を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式(GUI 上で設定)で作業が可能となり、ARK には、アプリケーションを操作(起動・停止・監視・再起動)するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 JP1/AJS3 の ARK としては、下記の通り大きく2つの種類があります。 ① Generic ARK for JP1/AJS3 Manager 「JP1/Base」と「JP1/Automatic Job Management System 3」(略称:JP1/AJS3)の「Manager」を,LifeKeeper の保護対象リソースとして登録し,保護する機能を提供します。 ② Generic ARK for JP1/AJS3 Agent 「JP1/Base」と「JP1/Automatic Job Management System 3」(略称:JP1/AJS3)の「Agent」を,LifeKeeper の保護対象リソースとして登録し,保護する機能を提供します。 JP1/AJS3 ARK は、汎用アプリケーション(Generic Application)リソースとして導入されます。 おさらいでお伝えした通り、「JP1/Base」と「JP1/Automatic Job Management System 3」のそれぞれを操作するため、起動・停止・監視・再起動を行うためのスクリプトが準備されており、リソース作成時にこれらのスクリプトを設定していきます。 この4つのスクリプトのうち、起動と停止は必須で、監視と再起動は任意となり、JP1製品の監視や再起動を実施する要件がなければ、対象のスクリプトを設定する必要もありません。 監視と再起動を導入しなければ、LifeKeeper として JP1/AJS3 の障害を検知することはなく、フェイルオーバーの対象にもなりません。また、監視は行うが、再起動は行わないことも出来ます。ただ、監視は行わず、再起動のみ行うことは出来ません。あくまでも監視で異常と検知された場合のみ、再起動が有効になります。 JP1/ASJ3 ARKを導入するための条件 JP1 が使用する共有ディスクリソースと,JP1 の論理ホスト名に紐づく仮想 IP リソースは、別で作成しておく必要があります。また、JP1 リソース作成後、共有ディスクリソースと仮想 IP リソースに対する依存関係を手動で設定する必要があります。 JP1/ASJ3 ARK の構築例 それでは、実際に JP1/AJS3 ARK の構築についてお話していきたいと思います。 スクリプトの修正 まずは、「JP1/Base」と「JP1/Automatic Job Management System 3」を操作するため、利用する全てのスクリプトを修正する必要があります。 スクリプトのパラメータ変更 次の変更可能なパラメータのうち、必要なパラメータを修正します。 ※下記パラメータ以外を変更してしまうとサポートが受けられなくなりますので注意してください。 <Windows版> 内容 パラメータ名 設定条件 リソースタグ名 APP 任意 論理ホスト名 VHOSTNAME 必須 JP1環境変数 JP1PATH 任意 タイムアウト値(処理待ち時間) DEFAULT_TIMEOUT 任意 タイムアウト値(後処理の待ち時間) HANDLE_STOP_TIMEOUT 任意 処理モード(※1) PROCESS_MODE 任意 ※1:停止スクリプトのみ提供されるパラメーター <Linux版> 内容 パラメータ名 設定条件 リソースタグ名 APP 任意 論理ホスト名 VHOSTNAME 必須 タイムアウト値(処理待ち時間) DEFAULT_TIMEOUT 任意 タイムアウト値(後処理の待ち時間) HANDLE_STOP_TIMEOUT 任意 待機時間(※2) APP_FORCE_STOP_WAIT_TIME 任意 ※2:監視スクリプトは設定不要なパラメーター (1)リソースタグ名(APP)の変更 リソースタグ名は保護対象リソースを一意に識別するための名称です。デフォルトで設定がされていますが、案件ごとに命名規則がありますので、案件にあったリソースタグ名に変更する必要があります。 (2)論理ホスト名(VHOSTNAME)の変更 論理ホスト名は JP1/AJS3 ARK で唯一の必須となるパラメータです。クラスタ環境(論理ホスト上)でJP1製品のコマンドを実行するため、論理ホスト名が必要になります。JP1/AJS3 ARK の各スクリプトでもJP1製品のコマンドを実行するため、必要不可欠なパラメータとなります。 (3)JP1環境変数(JP1PATH)の変更 ※Windows版のみ JP1環境変数は JP1 製品のコマンドを実行するためのパス名です。各スクリプトにはJP1製品のデフォルトのインストールパス名があらかじめ記載されており、明示的にインストールパスを変更してJP1製品をインストールする場合、このJP1環境変数を変更する必要があります。 (4)タイムアウト値(DEFAULT_TIMEOUT,HANDLE_STOP_TIMEOUT)の変更 タイムアウト値は各スクリプトに設定するタイマー監視用の値です。各スクリプトで実行した JP1 製品のコマンドが無応答となった場合、設定したタイムアウト値によってタイマー監視を行い、各スクリプトを終了させます。 基本的には変更することはありませんが、処理時間が遅いだけで問題もなく各スクリプトがタイムアウトとなってしまう場合、環境に合わせ変更する必要があります。 (5)処理モード(PROCESS_MODE)の設定 ※Windows版の停止スクリプトのみ 処理モードはJP1製品の停止処理が失敗した場合における、後続処理の続行可否を判断するためのパラメータです。 処理モードが「0」:JP1製品の停止コマンドが失敗した場合、異常終了と判断し、フェイルオーバーが中断されます。 処理モードが「1」:JP1製品の停止コマンドが失敗した場合、正常終了と判断し、フェイルオーバーが継続されます。 ※デフォルト値は「1」になります。 (6)待機時間(APP_FORCE_STOP_WAIT_TIME)の変更 ※Linux版の監視スクリプト以外 待機時間は各スクリプトで実行される JP1 製品の2重起動防止を目的とした強制停止コマンドの終了を待機する時間の値です。 JP1製品の強制停止コマンドの一部処理がバックグラウンドで実施され、待機時間を経過しても終了せず、その後の JP1 製品の開始に失敗することがある場合、デフォルトの5秒から変更する必要があります。 JP1/ASJ3 関連リソースの作成 前述の通り、JP1/AJS3 ARK では「JP1/Base」と「JP1/Automatic Job Management System 3」(Manager または Agent)のリソースを作成することが可能です。 この2つのリソースを LifeKeeper の GUI によって作成する流れを環境毎に例として紹介します。 <Windows版> 処理内容 JP1/Base JP1/Automatic Job Management System 3 リソース作成前のツリー構造 冗長化対象ノードの選択 保護アプリケーションの選択(汎用アプリケーション) Restore(起動)スクリプトの入力 Remove(停止)スクリプトの入力 QuickCheck(監視)スクリプトの入力 DeepCheck(詳細な監視)スクリプトの入力 ※対象無し LocalRecovery(再起動)スクリプトの入力 アプリケーション情報の入力 ※入力無し LocalRecoveryの有無の選択 ※デフォルト:有効 リソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードのリソース作成準備の確認結果 待機系ノードの優先順位の設定 ※デフォルト:10 待機系ノードのリソース作成結果 リソース作成後のツリー構造 <Linux版> 処理内容 JP1/Base JP1/Automatic Job Management System 3 リソース作成前のツリー構造 保護アプリケーションの選択(Generic Application) 稼働系ノードのSwitchbackタイプの選択 ※デフォルト:intelligent 稼働系ノードの選択 Restore(起動)スクリプトの入力 Remove(停止)スクリプトの入力 QuickCheck(監視)スクリプトの入力 LocalRecovery(再起動)スクリプトの入力 稼働系ノードのアプリケーション情報の入力 ※入力無し リソース作成時の起動有無の選択 稼働系ノードのリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト:intelligent 稼働系ノードの優先順位の設定 ※デフォルト:1 待機系ノードの優先順位の設定 ※デフォルト:10 待機系ノードのリソース作成準備の確認結果 待機系ノードのリソースタグ名の入力 待機系ノードのアプリケーション情報の入力 ※入力無し 待機系ノードのリソース作成結果 リソース作成後のツリー構造 これで、LifeKeeper による JP1/AJS3 製品 のリソースが完成です。 依存関係の作成 「JP1/Base」と「JP1/Automatic Job Management System 3」(Manager または Agent)のリソースを作成した後、全リソースの起動(停止)する順序を定義するため、リソース間の依存関係(リソースツリーの下から起動され、上から停止される)を作成する必要があります。 例として、別で作成していた共有ディスクリソースと,仮想 IP リソースを始めに起動させるようリソースツリーの下部に配置させ、その後に JP1/Base、JP1/AJS3 の順番で起動させるように依存関係を作成します。 処理内容 Windows版 Linux版 依存関係作成前のツリー構造 JP1/Baseリソースの依存関係作成後 JP1/AJS3リソースの依存関係作成後 これで、JP1/AJS3 製品に関連する LifeKeeper によるリソース構成ツリーの完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、JP1/AJS3 製品のリソース作成について紹介してみました。 JP1/AJS3 ARK を購入することで、正式なサポートを受けられるほか、LifeKeeper として JP1/AJS3 を操作(起動・停止・監視・再起動)するための4つのスクリプトがあらかじめ準備されており、必要最低限の修正だけで簡単にリソースとして導入が可能となっています。 LifeKeeper では JP1/AJS3 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 最後に JP1/AJS3 ARK を導入するための手順を纏めます。 ・JP1/Base と JP1/AJS3 で利用されるスクリプト内の変更可能なパラメータを修正する ・LifeKeeper GUI を用いて、JP1/Base と JP1/AJS3 のリソースを作成する ・共有ディスクリソースと仮想 IP リソース含め、リソースの起動順序を定義するため依存関係を作成する   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで