Storage

1. 背景: Windows パスワード更新直後に発生する Veeam サービス起動停止 企業の IT インフラ運用現場では、セキュリティ診断ガイドラインや定期的な資格情報更新ポリシーに従い、Windows Server のローカル管理者（Administrator）パスワードの変更や専用管理アカウントへの移行が実施されます。 しかし、**Veeam Backup & Replication（VBR）**が稼働するバックアップ管理サーバー上で Windows のパスワードを変更した直後、以下のような問題が発生し緊急障害へと発展するケースが多発します。 Veeam Backup & Replication Console 起動時にログオン画面で停止、または接続エラーが発生する。 Windows イベントログに Event ID 7000 / 7038（ログオンの失敗によりサービスを開始できませんでした） が記録される。 サービス管理画面（services.msc）から手動で起動を試みると エラー 1069（ログオン失敗） が返される。 [Windows サービスエラーメッセージ] エラー 1069: ログオンに失敗したため、サービスを開始できませんでした。 (Error 1069: The service did not start due to a logon failure.) この現象は、Veeam のバックアップエンジンやカタログサービス、ブローカーなどの中核バックグラウンドサービスが、インストール時に指定した管理者アカウント権限で稼働するように登録されているために発生します。Windows アカウントのパスワードのみを変更し、サービスプロパティ内の認証情報を更新しない場合、サービスの認証が通らず一斉に停止します。 2. 事前確認: 影響を受ける主な Veeam サービス一覧 Veeam サーバーには多数の常駐サービスが存在します。パスワード更新が必要となる代表的なサービスは以下の通りです。 サービス名 (Service Name) 表示名 (Display Name) 役割 VeeamBackupSvc Veeam Backup Service バックアップ/リストア処理およびスケジュール制御の中核エンジン VeeamBrokerSvc Veeam Broker Service インフラ構成情報の通信ブローカーサービス VeeamCatalogSvc Veeam Guest Catalog Service ゲスト OS ファイルインデックスおよび検索管理 VeeamCloudSvc Veeam Cloud Connect Service クラウドリポジトリおよびテナント連携サービス VeeamEnterpriseManagerSvc Veeam Backup Enterprise Manager エンタープライズ統合管理 Web サービス VeeamRESTSvc Veeam Backup Server RESTful API Service VBR REST API 連携用エンドポイント [図 1] Windows サービス管理画面（services.msc）の Veeam サービス一覧とプロパティメニュー ...

1. はじめに：HPE Alletra 9000 系列ファームウェア更新の重要原則 企業の最重要ミッションクリティカル基盤を支える HPE Alletra 9060（Alletra 9000 / Primera アーキテクチャベース） ストレージは、デュアルまたはクアッドコントローラー構成により、完全無停止（Online）でのファームウェアアップグレードに対応しています。 Alletra 9000 系列のOS更新において最も重要な前提条件は、最新の Upgrade Tool（UT）の事前準備です。ストレージOS本体を適用する前に、対象バージョンに対応した Upgrade Tool をシステムに先行登録しておくことで、正確な事前適合性チェック（Readiness Check）と安全なローリングノード再起動が実現します。 本記事では、実運用中の HPE Alletra 9060 実機をベースに、OS 9.6.5 から OS 9.6.30（Extended Support Release） への無停止アップグレード手順と現場での確認ポイントを解説します。 2. 作業前の事前準備とパッケージ入手 2.1. 必須パッケージの入手手順 Alletra 9000 および Primera のファームウェアとツールは、HPE 公式ライセンスポータルより入手します： HPE Enterprise License Portal（My HPE Software Center） へアクセス Software メニュー ➔ 保守契約情報（SAID）またはシリアル番号を入力 以下のパッケージをダウンロード： 最新 Upgrade Tool パッケージ: Upgrade Tool 80（build 260625） 以降 対象 OS ファームウェアパッケージ: HPE Alletra 9000 OS 9.6.30.xx（tar/iso 形式） 2.2. 事前確認チェックリスト ホスト I/O マルチパス（Multipath）正常性の確認: ノード再起動時に残存ノードへ I/O が集約されるため、接続ホスト（15台以上）のマルチパス稼働パスを確認 ストレージハードウェアおよびシステム健全性の点検: コントローラーノード、電源モジュール、ドライブエンクロージャーの正常性（OK）および未解決アラート（New alerts: 0）の確認 備考（Remote Copy およびスケジュールジョブ）: 最新の Alletra/Primera OS はノードのローリング再起動時にもリモートコピー（Remote Copy）セッションやスケジュールを安全に自律制御するため、特定のリリースノート・アドバイザリ（Advisory）がない限り、手動停止を行わずオンラインのまま作業を進めます。 3. ステップ別 無停止アップグレード実務手順 Step 1. 事前ダッシュボードおよびシステム健全性の点検 Webコンソールにログインし、システムアラート（New alerts: 0）、利用可能容量、ホスト接続状態を確認します。System ➔ Software より現在の稼働バージョン（9.6.5）を確認します。 ...

1. はじめに：10.6.0 全面刷新とホワイトツリーUIの導入背景 HPEの次世代モジュラー型オールNVMeストレージである HPE Alletra Storage MP（B10120 / B10K）環境において、OSファームウェアが10.6.0 へアップデートされたことに伴い、システム管理インターフェースが大幅に刷新されました。 従来の10.5.x系まで採用されていた単一階層のダークサイドバーUIから脱却し、10.6.0からは クラウドネイティブ感覚のモダンなホワイトテーマと、直感的な多階層ツリーナビゲーション構造 が新たに導入されています。 本記事では、実機環境の Alletra Storage MP B10K をベースに、10.6.0 新UIにおけるメニュー構造の変化点と、エンジニアリング実務の観点から重要なモニタリングポイントを整理して解説します。 2. 10.5.x vs 10.6.0 UI比較 比較項目 従来UI (OS 10.5.50 以前) 新規UI (OS 10.6.0) 実務におけるメリット テーマデザイン 暗いダークグレーのサイドバー 明るくモダンなホワイトカードベースUI 視認性が大幅に向上、最新HPE GreenLake統合ルック＆フィール 左側ナビゲーション 単純なアイコン中心の単一階層 テキストラベル付き多階層折りたたみツリー 下位メニュー（ドライブ、ポート等）へ1クリックで即時遷移可能 上部ブランディング 基本シンボルアイコンのみ表示 HPEロゴおよび製品モデル名を明記 複数ストレージの同時運用時における識別性が向上 ポート/スイッチ管理 詳細ハードウェア配下を探索 Ports / Switches が独立メニューとして常時表示 SANファブリックのリンク状態やポート速度を即座に確認可能 セキュリティ・設定統合 各所に分散していた設定項目 Settings 配下にネットワーク/テレメトリ/証明書を集約 セキュリティポリシー（ランサムウェア検知、保持期間）のワンストップ設定 アップグレード前／後の System 画面比較 図 1. [アップグレード前] OS 10.5.50 ダークサイドバー採用の従来 System ダッシュボード画面 ...

1. 背景: Alletra MP 10.6.0 アップグレードと新UIへの刷新 ミッションクリティカルストレージである HPE Alletra Storage MP (B10K / B10120)において、システムの安定性向上と最新機能のサポートを目的とした10.6.0 OSファームウェアアップグレード を実施しました。 今回の10.6.0リリースは、バックエンドの性能向上とプラットフォームの安定化だけでなく、Web管理コンソールが従来のダークサイドバーからモダンなホワイトツリー型新UIへと大幅に刷新される重要なアップデートとなっています。 ストレージがインターネット(HPE Cloud Connect)に接続されている環境であれば、10.6.0ファームウェアパッケージが自動的にStaged(事前ダウンロード) されているため即座に作業を開始できます。閉域網環境の場合でも、ローカルコンソールからファイルを直接アップロードして安全に適用可能です。 2. 環境および前提条件 項目 スペック / 設定情報 実務上の設定理由 対象ストレージ HPE Alletra Storage MP B10120 2ノード アクティブ-アクティブ エンタープライズブロックストレージ 現行OSバージョン OS 10.5.50 既存稼働ファームウェアバージョン ターゲットOSバージョン OS 10.6.0 (ArcusOS) 新UI対応およびプラットフォーム安定化推奨バージョン パッケージ準備方式 オンラインStaged / ローカルファイル手動アップロード インターネット接続時は10.6.0自動受信済み 事前必須検証 System Readiness Checks アップグレード前に100% Passed確認が必須 想定所要時間 約60分 〜 90分程度 ノード順次再起動およびCDMコンポーネント書き込み含む 3. 実践アップグレード手順 (ステップ別) Step 1. 現在のOSバージョンおよびダッシュボード状態の点検 作業を開始する前にオンプレミスWebコンソールへログインし、System ➔ Dashboard にて現行OSバージョン(10.5.50)と各コントローラー、シャーシ、IOMモジュールの正常稼働状態(OK)を点検します。 ...

1. 背景: サーバールームは低温なのに、なぜスイッチ前面にAmber LEDが点灯するのか？ データセンター現場での保守作業時、室温は18〜20°Cと十分に涼しく保たれているにもかかわらず、Cisco MDS 9148T (HPE SN6620C) ストレージスイッチ前面パネルのSYS/ENVステータスLEDがオレンジ色(Amber)に点灯している現象によく遭遇します。 実際に show environment コマンドで内部センサー温度を確認すると 32°C (Normal) と極めて正常な状態であるにもかかわらず、NX-OS 9.2.2 のセンサーポーリング処理バグ(CSCwo09244等)によって閾値超過アラートが誤検知され、警告灯が点灯してしまうのが原因です。 本記事では、温湿度センサー誤診断によるAmber LED問題の原因と、推奨安定版9.4.5へのアップグレードによる根本的解決手順、さらに障害解析時にログのタイムスタンプ齟齬を防ぐためのタイムゾーン(Timezone)設定方法を整理します。 2. 環境および前提条件 項目 スペック / 設定情報 実務上の設定理由 対象機器 Cisco MDS 9148T / HPE SN6620C 32G Enterprise FC SAN スイッチ 発生バージョン Cisco NX-OS 9.2(2) 温湿度センサーポーリング誤診断バグが存在 対処完了バージョン Cisco NX-OS 9.4(5) センサーポーリングおよびプラットフォーム監視バグ修正済み 適用タイムゾーン Timezone (KST/JST, UTC+9) 標準時基準でのログ解析同期化 3. 実践対処および設定手順 作業前のスイッチ前面LEDおよびステータス点検画面 Step 1. 温湿度センサーおよび環境ステータスの点検 前面のAmber LEDが点灯した際、ハードウェア故障かソフトウェアバグかを切り分けます。 # 環境センサーおよび温度情報の詳細確認 show environment temperature 出力結果で全センサー項目が OK かつ正常温度範囲(Normal)内にあるにもかかわらずAmber LEDが消灯しない場合、NX-OS 9.2.2 のセンサー誤診断バグであると判断できます。 ...

1. 背景: なぜ 9.4.5 バージョンへのアップグレードが必要だったのか？ HPE SN6620C (Cisco MDS 9148Tベース) 32Gb FC SANスイッチを運用中のお客様環境において、安定性向上のためのファームウェア更新を実施しました。 旧バージョンの9.2.2では、長期稼働時の環境センサー誤検知やISSU実行時のBIOSタイムアウトの懸念が報告されていました。そのため、HPEおよびCisco公式の 推奨安定バージョン(Recommended Release)であるNX-OS 9.4(5)へのアップグレードを決定しました。 外部接続が遮断された閉域網環境であるため、エンジニアの作業用ノートPCにRebex Tiny SFTP/SCP Serverを起動し、ローカル接続でファームウェアを転送する方式を採用しました。 2. 環境および前提条件 項目 スペック / 構成情報 実務上の設定理由 対象スイッチ HPE SN6620C (Cisco MDS 9148T OEM) 32Gbps ファイバチャネル(FC) SAN スイッチ 現行 NX-OS バージョン 9.2(2) 既存稼働バージョン ターゲット NX-OS バージョン 9.4(5) HPE/Cisco 推奨安定版 (Recommended) 転送プロトコル SCP (Secure Copy Protocol) 作業PC ↔ スイッチ Managementポート直結転送 SCP サーバーツール Rebex Tiny SFTP/SCP Server インストール不要のポータブルSCPサーバー ファームウェアファイル m9000-pkg2.9.4.5.bin, m9000-kickstart-pkg2.9.4.5.bin システム(System)およびKickstartバイナリパッケージ 3. 実践アップグレード手順 (ステップ別) Step 1. 現在のOSバージョンおよびスイッチ状態の確認 作業開始前にスイッチCLIに接続し、現行バージョン(show version)とモジュール/ポート状態(show module)を点検します。 ...

ベンダーの公式マニュアルは存在しますが、本記事は実際の現場でHPE Alletra 6000の新UIを使用してOSアップグレードを実施した際の実務記録です。初めて作業する方にとって、UI画面のキャプチャがないとファームウェア更新のイメージを掴みにくい場合があるため整理しました。現場の環境やバージョンによって順序が若干異なる場合がありますので、実務の参考としてご活用ください。 📌 作業概要 現在のOSバージョン: 6.1.2.500 ターゲットOSバージョン: 6.1.3.300 所要時間: 約 2時間前後（ダウンロード、ノードの順次再起動、ファームウェア適用時間を含む） 1. ファームウェアイメージの準備 (インターネット vs ローカル) AlletraストレージはOSアップデートファイルの準備方法として2つの方式をサポートしています。 インターネット直接ダウンロード: ストレージが外部（HPE InfoSight等）と通信可能な環境であれば、UI上から直接最新バージョンを確認してダウンロードできます。 ローカルファイルアップロード: 閉域網環境や特定バージョンを手動適用する場合、PCに事前ダウンロードしたファイルをブラウザ経由でアップロードします。 Alletra 新UI メインダッシュボード画面 2. アップグレード手順 Step 1. ソフトウェア(Software)メニューへ移動 管理者アカウントでログイン後、メインメニューの ソフトウェア(Software) 項目へ移動します。現在インストールされているバージョン(6.1.2.500)と利用可能なアップデート情報が表示されます。 ソフトウェア管理メニュー画面 Step 2. ファームウェアファイルのダウンロード/アップロード 選択した方式に応じて手順を進めます。 インターネット直接ダウンロード: 「ダウンロード」ボタンをクリックすると、利用可能なOSバージョン一覧が表示されます。 ローカルアップロード: 「Browse(参照)」ボタンを押して、ローカルPCのファームウェアファイル(.iso/.img)を選択しアップロードを実行します。 ダウンロードボタンクリック時に表示される利用可能OSバージョン一覧画面 ローカルアップロード用ファームウェアファイルを選択するため「Browse(参照)」ボタンを押す画面 選択したファームウェアファイルのアップロード進行画面 インターネットダウンロードおよびファイル適用進捗画面 Step 3. 事前チェック (Pre-check) および Updateボタンの有効化 ファイルの準備が完了すると、システム事前チェック(Pre-check)が自動実行されます。(※キャプチャ漏れ) チェック結果が正常(Passed)になると、無効化されていたUpdate(アップデート)ボタンが有効化されます。 Step 4. UpdateボタンのクリックとEULAライセンス同意 有効化されたUpdateボタンを押すと、最終EULAライセンス同意ポップアップが表示されます。内容を確認し同意を進行します。 Updateボタンクリック後に表示されるEULAライセンス同意画面 Step 5. OSおよびファームウェア更新の進行状況モニタリング ライセンス同意完了後、コントローラーノードが順次再起動しながらファームウェアが適用されます。新UIでは進捗率(%)がリアルタイムで表示されます。 OSアップデート進行画面 Step 6. アップグレード完了と最終バージョンの確認 すべてのノードの再起動と適用が完了したら、ダッシュボードでターゲットバージョン(6.1.3.300)が正しく反映されているか確認します。 ...

24時間365日稼働する本番DBやサービスサーバーのディスク使用率が90%を超えた際、メンテナンス停止を伴わずに **「オンライン状態で安全にディスクを拡張できるか」**は現場エンジニアの必須スキルです。 RHEL/Rocky Linux/CentOS (7 〜 9) や Ubuntu (20.04 〜 24.04 LTS) など、仮想化（VMware、KVM、Nutanix、SimpliVity）やクラウド環境において、サーバーの再起動やアンマウント（umount）を行わず、完全無停止でディスクを拡張する標準手順をまとめました。 1. 全体作業フロー（4ステップ） flowchart LR A["1. 仮想ディスク/ストレージ増設"] --> B["2. LinuxカーネルSCSI再スキャン"] B --> C["3. LVM拡張 (pvresize / lvextend)"] C --> D["4. ファイルシステム拡張 (xfs_growfs / resize2fs)"] 2. Step 1: SCSIバス再スキャンによる容量認識 ハイパーバイザ側でディスクサイズを拡張後（例: 100GB -> 200GB）、Linuxカーネルに再認識させます： # 対象ディスクが /dev/sdb の場合 echo 1 > /sys/class/block/sdb/device/rescan # 認識確認 lsblk /dev/sdb dmesg | tail -n 15 3. Step 2: パーティションテーブルの拡張（必要な場合） パーティション（/dev/sdb1）を切っている場合は growpart で拡張します（ディスク直PVの場合は不要）： ...

データセンターにおいて重要ストレージを相互接続するバックボーンであるCisco MDS SANスイッチを安定稼働させるには、ハードウェア状態（ファン、電源、温度）やFCポート障害、ファブリック構成変更をNMS（Zabbix、PRTG等）と連携してリアルタイムに監視することが不可欠です。 MDSスイッチのSNMP設定で最も頻発する誤用が、snmp-server enable traps で全トラップを一括有効化してしまうことです。これにより軽微なデバッグイベントまでNMSへ大量送信され、トラップストーム（Trap Storm）が発生してスイッチCPUおよび監視サーバーに不要な負荷を与えてしまいます。 実務においては、公式ガイドに準拠し、監視対象とすべき重要MIBトラップのみを厳選して有効化することが標準的な運用プラクティスです。 本記事では、SNMP v2c基本設定（Community、Host）から必須MIB通知の選別設定、コンフィグ保存・検証、およびNMS用MIBファイルの入手先までをコマンドベースで解説します。 1. 事前準備とパラメータ設定例 練習および現場適用環境の基本パラメータは、以下のように定義されます。 アイテム 例設定値 説明 装備モデル Cisco MDS 9148S SANファブリックスイッチ SNMP バージョン v2c 実際に最も広く使用されている標準 SNMP バージョン **Community String ** SDS(例) セキュリティのためにデフォルトの publicの代わりに組織標準名を使用する アクセス権限 ro(Read-Only) NMS収集のための読み取り専用権限 **NMS監視サーバーIP ** 192.168.100.10 Trapイベントを受信する監視サーバーのIP Trap 受信ポート UDP 162 標準SNMP Trapポート 2. デフォルトの SNMP 環境設定 (Community & Host Trap) まず、ターミナルコンソールまたはSSHでMDSスイッチに接続し、グローバル設定モード（ config terminal）に入ります。 2.1。命令実行 # 전역 설정 모드 진입 conf t # 1. SNMP Community String 생성 및 Read-Only(ro) 권한 부여 snmp-server community SDS ro # 2. NMS 모니터링 서버로 SNMP Trap 전송 설정 (버전 v2c) snmp-server host 192.168.100.10 traps version 2c SDS 2.2.端末実行画面 ...