memo.

カテゴリー: 技術系

  • F5 BIG-IP 仮想ロードバランサで、一部のアプリケーションサーバにのみ通信ができない

    Cisco NEXUS でVPC構成（VLAN多数）、VMware ESXiによる仮想化、F5 BIG-IPの仮想ロードバランサ、ロードバランサの配下に複数のアプリケーションサーバ、という構成で、ロードバランサの下のAPサーバに通信がうまくできない、という状態が発生した。

    状況を切り分けしてみると、下記のような状態になった。

    端末→ESXi→Cisco NEXUS （A）→ESXi→BIG-IP→アプリサーバ（X）　・・・　通信OK

    端末→ESXi→Cisco NEXUS （A）→ESXi→BIG-IP→アプリサーバ（Y）　・・・　通信OK

    端末→ESXi→Cisco NEXUS （B）→ESXi→BIG-IP→アプリサーバ（X）　・・・　通信NG

    端末→ESXi→Cisco NEXUS （B）→ESXi→BIG-IP→アプリサーバ（Y）　・・・　通信NG

    ※Cisco NEXUSは、2台（AとB）で、VPC（Virtual Port Channel）構成で、L3の役割を行っている。基本的に、VLANを超えるときは、必ずL3のNEXUSを通過する。

    ※端末と、APサーバ、BIG-IP仮想ロードバランサは、それぞれ別のネットワークに属する。

    最初は、L3スイッチである、NEXUSの設定を疑ったのだが、AとBで差異はなく、VPCとしての動作も問題がなかった。BIG-IPを経由しなければ、AとBのどちらのNEXUSを通過しても問題発生しない。

    BIG-IPの仮想ロードバランサでの通信制御が不具合につながっている可能性が高いことがわかった。BIG-IP仮想ロードバランサの設定を見ていくと、「Auto Last Hop」の設定がONになっており、これが影響していることがわかった。上位のスイッチであるL3のNexusは2台あるので、アクセスしてきたアクセス経路に通信を返す、のが正しいように見える。しかし、VPC構成になっているで、仮想MACアドレスで制御されているのため、アクセス元のスイッチに返してしまうと、経路が途中で変わってしまい、アクセス元の端末までパケットが届かない。

    BIP-IPのほうも、上位スイッチが冗長構成を行っている場合は、「Auto Last Hop」の設定は、オフ（無効）にすることが推奨されている。「Auto Last Hop」の設定をオフにすることで、無事に、AとBのどちらのNexusを経由しても、BIP-IP仮想ロードバランサの下のAPサーバと通信できるようになった。

    「Auto Last Hop」の設定は、BIG-IP仮想ロードバランサの設定画面で、

    「System」→「Configuration」→「Local Traffic」

    の順に選択する。Generalのプロパティに、「Auto Last Hop」の項目があるので、「Enabled」のチェックを外して保存する。

    Auto Last Hopの説明

    https://www.infraexpert.com/infra/bigip29.html

  • VBScriptの寿命もあとわずか

    MicrosoftがWindows環境におけるVBScript（VBS）を非推奨にすると発表した。将来的には、VBScriptの実行環境が削除されるとのこと。

    「VBScript」は非推奨に、将来のWindowsリリースで削除
    https://forest.watch.impress.co.jp/docs/news/1537619.html

    しぶとく残ると思われていたIE11も廃止されたので、VBScriptも確実に削除されるだろう。いずれ出るであろうWindows 12は、削除されていてもおかしくはないかも。そう考えると、明確な言及はないけれど、2，3年くらいで無くなるという覚悟が必要そうだ。

  • メモ：GitLab CE 16.2からGitLab CE 16.4.1にアップデートした。

    また、小まめにGitLab CEのアップデートをやり忘れて、apt updateでのアップデートでエラーになった。今回は、GitLab CE 16.2から、GitLab CE １6.4.1へのアップデートだ。

    apt upgradeで発生したエラー（一部抜粋）は下記。

    gitlab preinstall: It seems you are upgrading from 16.2 to 16.4.
gitlab preinstall: It is required to upgrade to the latest 16.3.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: アーカイブ /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
 new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
 /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

    まずは、GitLabのサイトで、アップグレードできるパスを調べる。

    https://docs.gitlab.com/ee/update/index.html#upgrading-to-a-new-major-version

    これによると、一度、16.3.5にアップグレードしてから、この時点の最新にアップグレードする必要があるとのこと。

    アップグレードパス　：　16.2 → 16.3.5 → 16.4.1

    これを実行したコマンドは下記。段階的にアップデートして、最後に、GitLabを再起動する。

    sudo apt update
sudo apt upgrade gitlab-ce=16.3.5-ce.0
sudo apt upgrade gitlab-ce=16.4.1-ce.0
sudo gitlab-ctl restart

    何度もやっているので、作業自体はこなれた感じだ。

  • systeminfoは、WindowsXP以降に追加されたコマンド

    タイトルのままだが、systeminfoは、Windows XPから追加されたコマンド。Windows 2000（Windows 2000 Server）には、systeminfoがないので注意。

  • SQL Server エージェントのジョブの権限を与える方法

    SQL Serverで、個別のデータベースに対して、権限を与えても、SQL Server エージェントのジョブの部分はSQL Server Management Studio（SSMS）には、「SQL Server エージェント」も「ジョブ」も表示されない。これの権限は、データベースの権限とは別につける必要がある。

    SQL Serverのジョブ（SQL Server エージェント）に権限を付ける一番簡単な方法は、以下の操作でsysadmin権限の付与を行う。

    1. SSMSを使って、管理者権限のあるユーザでSQL Serverに接続する。
    2. SSMSのオブジェクトエクスプローラーで、「セキュリティ」「サーバー ロール」の順に開く（展開する）。
    3. サーバーロールに表示された「sysadmin」を右クリックして、プロパティを開く。
    4. プロパティの「メンバー」の「追加」をクリックする
    5. 権限を与えるユーザを指定して、OKをクリックする。

    これで権限が付与されるので、権限を与えたユーザで、SSMSで接続して、「SQL Server エージェント」と「ジョブ」が表示されることを確認する。

    もし、SQL Server エージェントだけの権限を与える必要がある場合は、データベースの「msdb」にあるロールを割り当てる。

    1. SSMSを使って、管理者権限のあるユーザでSQL Serverに接続する。
    2. 「セキュリティ」、「ログイン」から、SQL Server エージェントを使わせるユーザのプロパティを開く
    3. 「ユーザーマッピング」を開く。
    4. 「msdb」にチェックをいれ、選択した状態にする
    5. ロールの「SQLAgent～～～」で、最適な権限を選択して、OKをクリックする。

    選択できるロールの概要は以下。

    SQLAgentUserRole
    →SSMSで接続したときに、SQL Serverエージェントが表示される。
    　表示されるのは、接続ユーザの権限があるもののみ。

    SQLAgentReaderRole
    →SSMSで接続したときに、SQL Serverエージェントが表示される。
    　他のユーザのSQL Serverのジョブも表示される。
    　メニューで、ジョブが実行できるように見えるが、実行すると権限がないものはエラーになる。

    SQLAgentOperatorRole
    →SSMSで接続したときに、SQL Serverエージェントが表示される。
    　SQL Serverのジョブの表示や実行ができる。

    参考： https://learn.microsoft.com/ja-jp/sql/ssms/agent/sql-server-agent-fixed-database-roles?view=sql-server-ver15

  • Windows 2000 Serverは、Windows Server 2022のADに参加できない

    Windows Server 2022で作成したAD（機能レベル2016）に、Windows 2000 Serverを参加させようとしたが、エラーによりドメインに参加できなかった。

    ドメイン "xxxxxx.domain" に参加中に次のエラーが発生しました：
指定されたネットワーク名は利用できません。

    原因は、CIFSなどのプロトコルのバージョンが低いもの（セキュリティリスクがあるもの）を許可していないためと思われる。参加できるかどうかの実験だったので、通常状態ではWindows Server 2022で作成したADに、Windows 2000 Serverは参加できない、という結果が出たので満足。

  • Veeam Backup ＆Replication 11で設定できるイミュータブル期間の最大期間

    Veeam Backup＆ Replicationで設定できるイミュータブル期間（データの変更を禁止する不変期間）を調べてみた。

    https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110

    バックアップファイルは、構成された期間（最小7日、最大— 9999）の間イミュータブルになります。イミュータビリティ期間は、アクティブなバックアップチェーンに対してのみ延長されます。 バックアップに複数のチェーンがある場合、Veeam Backup & Replicationは、チェーン内の古いバックアップのイミュータビリティを延ばしません。

    https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110

    上記がVeeamのサイトにあるので、イミュータブル期間の最大期間は、9999日。無限にはできない。年にすると、 27.38年になる。

  • SQL Server でストアドプロシージャの一覧を表示する

    SQL Serverでストアドプロシージャの一覧を表示するためには、「INFORMATION_SCHEMA」の「ROUTINES」ビューを参照する。’ROUTINE_TYPE’で’PROCEDURE’ を指定することでプロシージャのみに絞り込める。絞り込みを行わない場合は、FUNCTION なども表示される。

    ■プロシージャのみで絞り込み

    SELECT
    *
FROM
    INFORMATION_SCHEMA.ROUTINES
WHERE
    ROUTINE_TYPE = 'PROCEDURE'
ORDER BY
    SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME

    ■プロシージャだけでなく、ファンクションも表示する

    SELECT
    *
FROM
    INFORMATION_SCHEMA.ROUTINES
ORDER BY
    SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME

    ■必要なものだけ表示する

    SELECT
    SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME, ROUTINE_CATALOG, ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM
    INFORMATION_SCHEMA.ROUTINES
ORDER BY
    SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME

    参考：

    INFORMATION_SCHEMA.ROUTINES　の説明

    現在のデータベースの現在のユーザーがアクセスできるストアド プロシージャと関数ごとに、1 行のデータを返します。 戻り値を記述する列は、関数にのみ適用されます。 ストアド プロシージャの場合、これらの列は NULL になります。

    https://learn.microsoft.com/ja-jp/sql/relational-databases/system-information-schema-views/routines-transact-sql?view=sql-server-ver16

  • Veeam Backup & Replication 11で必要なメモリサイズ

    1台のサーバに、データの保存先を含めたVeeam Backup ＆ Replicatiion 11の全機能をインストールするときに必要なメモリサイズを計算する。同時に実行するタスクの数により、必要なメモリとCPUのコア数が変わる。4タスクを同時に動かす想定。

    4タスクを同時実行する、1台構成のVeeamのメモリとCPU

    ■メモリサイズ

    基本　　4GB
    コンソール　0GB（2GB　‐　2GB）
    プロキシサーバ　6GB（2GB　x 4タスク ‐ 2GB）
    バックアップリポジトリサーバ　10GB（4GB　＋　2GB　x　4タスク　‐2GB）
    ※1台に複数機能を入れる場合には、1機能あたり、2GBを引けるとのこと
    ※バックアップリポジトリを分割すると、半分の10GBで済む。その場合は、バックアップリポジトリサーバは、12GBのメモリが必要になる想定。

    合計　20GB

    ■CPUのコア数

    基本　4コア
    プロキシサーバ　4コア（1コア　x　4タスク）

    合計　8コア

    ここでの計算が漏れている可能性もあるため、余剰でメモリを割り当てられるのであれば、もっと多いメモリサイズを割り当てた方がよい。

    参考：　　https://helpcenter.veeam.com/jp/archive/backup/110/vsphere/system_requirements.html

  • Veeam Backup & Replication 12で必要なメモリサイズ

    1台のサーバに、データの保存先を含めたVeeam Backup ＆ Replicatiion 12の全機能をインストールするときに必要なメモリサイズを計算する。同時に実行するタスクの数により、必要なメモリとCPUのコア数が変わる。4タスクを同時に動かす想定。

    なお、バージョン12では、バックアッププロキシでの複数タスクの実行で消費されるメモリが少なくなっている。

    4タスクを同時実行する、1台構成のVeeamのメモリとCPU

    ■メモリサイズ

    基本　　6GB（4GB　＋　0.5GB　x4タスク）
    コンソール　0GB（2GB　‐　2GB）
    プロキシサーバ　2GB（2GB　+ 0.5GB　x 4タスク ‐ 2GB）
    バックアップリポジトリサーバ　6GB（4GB　＋　1GB　x　4タスク　‐2GB）
    ※1台に複数機能を入れる場合には、1機能あたり、2GBを引けるとのこと
    合計　14GB

    ■CPUのコア数

    基本　4コア
    プロキシサーバ　4コア（1コア　x　4タスク）
    合計　8コア

    ここでの計算が漏れている可能性もあるため、余剰でメモリを割り当てられるのであれば、もっと多いメモリサイズを割り当てた方がよい。

    参考：　

    https://helpcenter.veeam.com/docs/backup/vsphere/system_requirements.html?ver=120