Veeam Log Diving のコンポーネントと用語集

Veeam ではログを重視しています。当社のソリューションのほとんどはモジュール式であるため、大量のログが書き込まれます。そして、私たちの活動分野はあなたのデータの安全性（つまり、ぐっすり眠ること）を確保することなので、ログはすべてのくしゃみを記録するだけでなく、かなり詳細に記録する必要があります。これは、何かが起こった場合に、何が起こったのか、誰が責任を負うのか、次に何をする必要があるのか​​が明確になるために必要です。それは法医学のようなものです。どんな小さなことがローラ・パーマーの殺人犯を見つけるのに役立つかは決してわかりません。

そのため、ログに何を書き込むのか、どこに保存するのか、ログの構造に惑わされないためにはどうすればよいのか、ログ内で何を探すのか、といったことを一貫して説明する一連の記事を書くことにしました。

なぜ一連の記事を作成し、すべてを一度に説明しないのでしょうか?

どのログがどこにあり、そこに何が保存されているかを単にリストするだけでは、かなり絶望的な作業です。そして、この情報を最新の状態に保つことを考えるだけでも恐ろしいです。 Veeam Backup & Replication で可能なすべてのログ タイプを簡単にリストすると、小さな文字で書かれた数ページにわたる表になります。また、次のパッチがリリースされると、新しいログが表示されたり、古いログに保存されている情報のロジックが変更されたりする可能性があるため、公開時にのみ関連します。したがって、ログの構造とそこに含まれる情報の本質を説明する方がはるかに有益です。これにより、名前を記憶するよりも簡単に場所をナビゲートできるようになります。

したがって、テキストシートの深淵に突入しないように、この記事でいくつかの準備作業を行いましょう。そのため、今日はログ自体を詳しく調べるのではなく、さらに詳しく見ていきます。用語集をまとめて、ログ生成の観点から Veeam の構造について少し説明します。

用語集と専門用語

ここでまず第一に、ロシア語の純粋さを擁護する人々とオジェゴフ辞書の証人たちに謝罪する価値がある。私たちは皆、自分の母国語が大好きですが、IT 業界は英語で動いています。まあ、これは私たちが思いついたわけではなく、歴史的にそうなっただけです。それは私のせいではありません、彼は自分で来ました（c）

私たちの業界では、英語表現（および専門用語）の問題には独自の特徴があります。全世界が長い間「ホスト」や「ゲスト」のような無害な言葉で非常に具体的なことを理解してきたのに、国の6分の1では辞書をひくことによる壮大な混乱とよろめきが続いています。そして、厳密に義務的な議論「しかし、私たちの仕事では…」

さらに、一部の単語や表現は一般的になっていますが、Veeam 製品に固有の用語も存在します。それで、今、私たちはどの用語が何を意味するかについて合意し、今後、「ゲスト」という言葉は、職場で慣れているものではなく、この章に書かれていることを正確に意味します。はい、これは私の個人的な気まぐれではなく、業界で確立された用語です。彼らと戦うことは、ある意味無意味です。ただし、私はコメントで大いに笑うことを常に支持しています。

残念ながら、私たちの仕事や製品には多くの用語があるため、すべてを列挙することはしません。バックアップとログに関する情報の海で生き残るために最も基本的で必要なものだけ。ご興味のある方は、 記事を提案する 彼は同僚にテープについて説明し、機能のその部分に関連する用語のリストも提供しました。

ホスト： 仮想化の世界では、これはハイパーバイザーを備えたマシンです。物理、仮想、クラウド - 何でも構いません。何かがハイパーバイザー (ESXi、Hyper-V、KVM など) を実行する場合、その「何か」はホストと呼ばれます。 10 台のラックのクラスターでも、1.5 台の仮想マシン用のラボを備えたラップトップでも、ハイパーバイザーを起動すればホストになります。ハイパーバイザーが仮想マシンをホストするためです。 VMware はかつて、「ホスト」という言葉と ESXi をしっかりと結び付けたいと考えていたという話さえあります。しかし彼女は対処できなかった。

現代の世界では、「ホスト」の概念は「サーバー」の概念と実質的に融合しており、特に Windows インフラストラクチャに関しては、コミュニケーションに一定の混乱が生じています。したがって、私たちにとって興味深いサービスをホストするマシンはすべて、ホストと呼ぶことができます。たとえば、WinSock ログでは、すべてが「ホスト」という単語でマークされます。典型的な「ホストが見つかりません」はその一例です。それでは、コンテキストから始めましょう。ただし、仮想化の世界では、ホストはゲストをホストするものであることを覚えておいてください (これについては、以下の 2 行で詳しく説明します)。

地元の専門用語 (または、この場合は頭字語) から、VMware は VI、vSphere は VC、Hyper-V は HV であることがわかります。

ゲスト： ホスト上で実行されている仮想マシン。ここで説明することは何もありません。すべてが非常に論理的でシンプルです。しかし、多くの人はここに他の意味を持ち込もうとします。

何のために？わからない。
ゲスト OS は、ゲスト マシンのオペレーティング システムです。等々。

バックアップ/レプリケーション ジョブ (jobA): 純粋にタスクの 1 つを表す Vim の専門用語です。バックアップ ジョブ == バックアップ ジョブ。これをロシア語に美しく翻訳する方法を誰も見つけられなかったので、誰もが「jobA」と言います。最後の音節に強勢を置きます。

はい、彼らはただ「ジョバ」と言うだけです。そして彼らは手紙でもこれを書いていて、すべてがうまくいっています。
あらゆる種類のバックアップ ジョブ、バックアップ タスクなど、ありがとうございます。ただし、必要ありません。ただ自分の仕事をしていれば、理解されるでしょう。重要なのは、最後の音節にアクセントを置くことです。

バックアップ (バックアップ、バックアップ。真の oldfags の場合、bakUp が許可されます): 明らかなこと (どこかにあるデータのバックアップ コピー) に加えて、ジョブ自体 (すでに忘れている場合は 3 行上) も意味し、その結果として、まさにそのバックアップ ファイルが表示されます。おそらく、英語を母国語とする紳士たちは、毎回「バックアップジョブを実行しました」と言うのが面倒なので、「バックアップを実行しました」とだけ言い、全員がお互いに完璧に理解し合うのです。私はこの素晴らしい取り組みを支援することを提案します。

統合: ESXi 5.0 で登場した用語。いわゆる孤立したスナップショットを削除するプロセスを開始するスナップショット メニューのオプション。つまり、物理的には存在するものの、表示される論理構造からは外れてしまったスナップショットです。理論的には、このプロセスはスナップショット マネージャーに表示されるファイルに影響を与えないはずですが、何が起こるかわかりません。統合プロセスの本質は、スナップショット (子ディスク) のデータがメイン (親) ディスクに書き込まれることです。ディスクを結合するプロセスをマージと呼びます。統合コマンドが発行された場合、スナップショットが統合されて削除される前に、スナップショット レコードがデータベースから削除されることがあります。また、何らかの理由でスナップショットを削除できなかった場合は、同じ孤立したスナップショットが表示されます。 VMwareはスナップショットの取り扱いについて言及している 悪くないKB。そして私たちも彼らについて Habrに書いた.

データストア（ストアまたはストレージ）:  これは非常に広い概念ですが、仮想化の世界では仮想マシンのファイルが保存される場所を指します。しかし、いずれにしても、文脈を非常に明確に理解し、少しでも疑問があれば、対話相手が正確に何を意味していたのかを明確にする必要があります。 

プロキシ： Veeam Proxy は、インターネットで慣れ親しんでいるものとまったく同じではないことをすぐに理解することが重要です。 Veeam 製品内では、これはある場所から別の場所へのデータの転送を処理する特定のエンティティです。あまり詳しく説明せずに言うと、VBR はコマンド サーバーであり、プロキシはその主力です。つまり、プロキシとは、トラフィックが流れるマシンであり、そのトラフィックの管理に役立つ VBR コンポーネントがインストールされています。たとえば、あるチャネルから別のチャネルにデータを転送したり、ディスクを自分自身に接続したりします (HotAdd モード)。

リポジトリ:  技術的には、これはバックアップが保存されている場所とその場所に接続する方法を示す VBR データベース内の単なるエントリです。実際には、単純な CIFS 共有、またはクラウド内の別のディスク、サーバー、バケットのいずれかになります。繰り返しになりますが、文脈上、リポジトリは単にバックアップが保存される場所であると理解しています。

 スナップショット（SnapshotOt）： オックスフォード文法愛好家たちは、誰がスナップショットで、誰がスナップショットかを言うことを好むが、文盲の大多数は質量が大きいため勝利する。ご存知ない方のために説明すると、これは特定の時点のディスクの状態を復元できる技術です。これは、I/O 操作をメイン ディスクから一時的にリダイレクトすることによって実行されます (これは RoW (Redirect on Write) スナップショットと呼ばれます)。または、書き換えられたブロックをディスクから別のディスクに移動することによって実行されます (これは CoW (Copy on Write) スナップショットと呼ばれます)。 Veeam がバックアップの魔法を発揮できるのは、まさにこれらの機能を幅広く使用できるからです。厳密に言えば、彼らだけではありませんが、これは今後数回のリリースの問題です。

ESXi のドキュメントとログではこの用語に関して混乱が生じており、スナップショットについて言及する文脈では、スナップショット自体、REDO ログ、さらにはデルタ ディスクも見つかります。 Veeam のドキュメントにはそのような混乱はなく、スナップショットはスナップショットであり、REDO ログは独立した非永続ディスクによって作成された REDO ファイルそのものです。 REDO ファイルは仮想マシンをオフにすると削除されるため、スナップショットと混同すると災害の原因となります。

合成： 合成バックアップは、逆増分バックアップおよび永久フォワードバックアップと呼ばれます。この用語をこれまで聞いたことがない場合、これは単にバックアップ チェーン変換を構築するために使用されるメカニズムの 1 つにすぎません。ただし、ログでは、増分から完全なコピーを作成するコンテキストで使用される変換の概念に遭遇することもあります (合成フル)。

タスク： これは、ジョブ内の各マシンを個別に処理するプロセスです。つまり、3 台のマシンを含むバックアップ ジョブがあります。つまり、各マシンは個別のタスク内で処理されます。合計で 4 つのログがあります。ジョブのメインのログが 1 つと、タスクのログが 3 つあります。しかし、ここには重要なニュアンスがあります。時間が経つにつれて、「taska」という言葉は過度に曖昧になってきたのです。一般的なログについて話すとき、タスクがまさに VM であることを意味します。しかし、プロキシとリポジトリの両方には独自の「タスク」があります。ここでは、仮想ディスク、仮想マシン、またはジョブ全体を意味する場合があります。つまり、文脈を失わないことが重要です。

Veeam %name% サービス:  バックアップを成功させるためにいくつかのサービスが機能しており、そのリストは標準装備に記載されています。それぞれの名称はそれぞれの本質を非常に明確に反映していますが、同等のサービスの中でも最も重要なのは Veeam Backup Service です。これがなければ、他のサービスは動作しません。

VSS： 技術的には、VSS は常に Microsoft Volume Shadow Copy Service の略です。実際、これは多くの人によってアプリケーション認識画像処理の同義語として使用されています。もちろん、これはまったくの嘘ですが、これは「どの SUV もジープと呼んでも理解してもらえる」というカテゴリーの話です。

幻想的な丸太とその生息地

この章の最初に、大きな秘密、つまりログに表示される時刻を明らかにしたいと思います。

覚えておいてください：

• ESXi は常に UTC+0 でログを書き込みます。
• vCenter はタイムゾーンの時間に基づいてログを保持します。
• Veeam は、ログが配置されているサーバーの時刻とタイムゾーンに基づいてログを保持します。
• また、EVTX 形式の Windows イベントのみが、何へのバインドの影響を受けません。開かれると、開かれたマシンの時間が再計算されます。最も便利なオプションですが、難しい点もあります。唯一の目立った難点はロ​​ケールの違いです。これは、ログが読み取り不可能になるパスであることがほぼ保証されています。はい、これを修正する方法はいくつかありますが、IT のすべてが英語で機能するという事実については議論せず、サーバー上で常に英語のロケールを設定することに同意しましょう。そうですね、お願いします。 

それでは、丸太が存在する場所と入手方法についてお話ししましょう。 VBR の場合、2 つのアプローチがあります。 

最初のオプションは、問題に特に関連するファイルを一般的なファイルの中から検索する気がない場合は適しています。このため、ログが必要な特定のジョブと特定の期間を指定できる別のウィザードがあります。次に、彼は自分でフォルダーを調べ、必要なものをすべて 1 つのアーカイブにまとめます。どこで探すか、どのように操作するかについては、 このKV.

ただし、ウィザードはすべてのタスクのログを収集するわけではなく、たとえば、復元、フェイルオーバー、フェイルバックのログを調べる必要がある場合、パスは次のフォルダにあります。 %ProgramData%/Veeam/バックアップ。これはメインの VBR ログ ストレージであり、%ProgramData% は隠しフォルダーですが問題ありません。ちなみに、デフォルトの場所は、HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication ブランチの REG_SZ タイプのレジストリ キー: LogDirectory を使用して再割り当てできます。

Linuxマシンでは、ワーカーエージェントのログは/var/log/VeeamBackup/root または sudo アカウントを使用している場合。そのような権限がない場合は、ログイン情報を確認してください。 /tmp/Veeamバックアップ. 

%OS_name%のVeeamエージェントのログは次の場所で検索されます %ProgramData%/Veeam/エンドポイント （または %ProgramData%/Veeam/バックアップ/エンドポイント）そして、 /var/log/veeam それぞれ。

アプリケーション対応の画像処理を使用している場合 (おそらく使用しているでしょう)、状況は少し複雑になります。仮想マシン自体に保存されているヘルパー ログと VSS ログが必要になります。この幸福をどこでどのように得るかは、 この記事。そしてもちろん 別の記事 必要なシステムログを収集します。 

Windowsイベントは、次のように便利に収集されます。 このKV。 Hyper-V を使用している場合は、アプリケーションとサービス ログ > Microsoft > Windows ブランチからのすべてのログも必要になるため、状況はさらに複雑になります。ただし、より直接的なアプローチを採用して、%SystemRoot%System32winevtLogs からすべてのオブジェクトを取得することもできます。

インストール/アップグレード中に何か問題が発生した場合、必要なものはすべて %ProgramData%/Veeam/Setup/Temp フォルダーにあります。ただし、OS イベントではこれらのログよりも有用な情報が見つかるという事実は隠しません。残りの興味深いものは %Temp% にありますが、主にデータベース、.Net ライブラリなどの関連ソフトウェアのインストールのログが含まれています。 Veeam は msi からインストールされ、GUI に表示されていない場合でも、そのすべてのコンポーネントも個別の msi パッケージとしてインストールされることに注意してください。したがって、いずれかのコンポーネントのインストールが失敗すると、VBR のインストール全体が停止します。したがって、ログにアクセスして、何がいつ壊れたのかを正確に確認する必要があります。

最後にもう 1 つのライフハック: インストール中にエラーが発生した場合は、急いで [OK] をクリックしないでください。まずログを取得し、「OK」をクリックします。この方法では、最後にゴミがなく、エラーが発生した時点で終了するログが取得されます。

そして、vSphere ログにアクセスする必要が出てきます。これは非常に感謝されない仕事ですが、袖をまくってやると、さらに悪いことをしなければなりません。最も単純なバージョンでは、仮想マシンのイベントを含むログ (.vmx ファイルの隣にあります) が必要になります。より複雑なケースでは、VMware はリリースごとにこの場所を変更することが多いため、Google を開いて、ホスト バージョンのログがどこにあるかを調べてください。ここでは、例えば、 7.0の記事、しかし 5.5。 vCenterログの場合は、手順を繰り返します。 グーグル検索。ただし、一般的には、ホスト イベント ログ hostd.log、vCenter によって管理されるホスト イベント vpxa.log、カーネル ログ vmkernel.log、および認証ログ auth.log に注目します。まあ、最も高度なケースでは、SSO フォルダーにある SSO ログが役に立つかもしれません。

かさばりますか？混乱した？怖い？そして、これは当社のサポートチームが日常的に扱う情報の半分にも満たないのです。本当に本当にかっこいいです。

Veeamコンポーネント

この入門記事の締めくくりとして、Veeam Backup & Replication のコンポーネントについて少しお話ししましょう。痛みの原因を探すときには、患者の体質を理解しておくとよいからです。

皆さんご存知のとおり、Veeam Backup はいわゆる SQL ベースのアプリケーションです。つまり、すべての設定、すべての情報、正常な機能に必要なすべてのものがデータベースに保存されます。より正確に言うと、VBR バンドルと EM バンドルの場合、それぞれ VeeamBackup と VeeamBackupReporting という 2 つのデータベースになります。そして、別のアプリケーションをインストールすると、別のデータベースが表示されます。全ての卵を一つのカゴに保管しないようにするためです。

しかし、これらすべてがスムーズに機能するためには、すべてのコンポーネントを結び付ける一連のサービスとアプリケーションが必要です。一例として、私のラボの 1 つでは次のようになります。

首席指揮者の役割は、 Veeam バックアップ サービス。データベースとの情報交換を担当するのは彼です。また、すべてのタスクの起動、割り当てられたリソースの調整を担当し、さまざまなコンソール、エージェント、その他すべてのものの通信センターとして機能します。一言で言えば、彼なしでは私たちはやっていけないのですが、だからといって彼がすべてを自分でやるというわけではありません。

彼は計画の実行に協力している Veeam バックアップ マネージャー。これはサービスではなく、ジョブを起動し、その実行プロセスを監視するエンティティです。バックアップ サービスの実務担当者。ホストへの接続、スナップショットの作成、保持の監視などを行います。

さて、サービスのリストに戻りましょう。 Veeamブローカーサービス。 v9.5 で登場しました (当時一部の人が考えていたように、これは暗号通貨マイナーではありません)。 VMware ホストに関する情報を収集し、最新の状態に保ちます。しかし、私たちがあなたをスパイし、すべてのログイン/パスワードをチーフに漏らしているなどと怒りのコメントをすぐに書き込まないでください。すべてが少しシンプルになります。バックアップを実行する場合、最初に行う必要があるのは、ホストに接続してその構造に関するすべてのデータを更新することです。かなりゆっくりで面倒な話です。 Web インターフェース経由でログインするのにかかる時間を覚えておいてください。また、そこでは最上位レイヤーのみがカウントされることを覚えておいてください。ちなみに、階層全体を適切な場所に開く必要があります。一言で言えば、ホラーです。バックアップを 5000 回実行する場合、各ジョブでこの手順を実行する必要があります。大規模なインフラストラクチャの場合、このプロセスには 100 分以上かかることがあります。そのため、常に最新の情報を受け取ることができる別のサービスを割り当てることが決定されました。起動時に、追加されたすべてのインフラストラクチャをチェックしてスキャンし、増分変更のレベルでのみ動作を試みます。したがって、同時に XNUMX 個のバックアップを実行している場合でも、それらはすべてブローカーに情報を要求するため、その要求によってホストに負担がかかることはありません。リソースが心配な場合は、当社の計算によると、XNUMX 台の仮想マシンに必要なメモリは約 XNUMX MB のみです。

次に Veeamコンソール。これは、Veeam Remote Console または Veeam.Backup.Shell とも呼ばれます。これはスクリーンショットで表示されるものと同じ GUI です。すべてがシンプルで明白です。Windows であり、VBR サーバーに接続できる限り、コンソールはどこからでも起動できます。唯一言えることは、FLR プロセスがポイントをローカル (つまり、コンソールが実行されているマシン) にマウントするということです。まあ、さまざまな Veeam Explorer もコンソールの一部であるため、ローカルで起動されます。しかし、これで私はすでに荒野へと連れて行かれてしまったのです...

次の興味深いサービスは Veeam バックアップ カタログ データ サービス。 サービスのリストでは、これは Veeam Guest Catalog Service として知られています。ゲスト マシン上のファイル システムをインデックス化し、その知識を VBRCatalog フォルダーに格納します。インデックスがチェックされている場合にのみ使用されます。 Enterprise Manager がある場合にのみこれを有効にするのが合理的です。したがって、私の心の底からのアドバイスは、EM がない場合は、インデックス作成をそのままオンにしないことです。神経とサポート時間を節約します。

注目すべきその他の重要なサービスは次のとおりです。 Veeamインストーラーサービスこれにより、プロキシ、リポジトリ、その他のゲートウェイに必要なコンポーネントの配信とインストールが行われます。実際には、必要な .msi パッケージをサーバーに配信してインストールします。 

Veeam データムーバー — プロキシ上で起動された補助エージェントの助けを借りて（そしてそれだけではない）、データの転送に携わります。たとえば、バックアップ中、1 つのエージェントがホスト データストアからファイルを読み取り、2 番目のエージェントがそれらのファイルをバックアップに慎重に書き込みます。

クライアントがよく反応する重要な点、つまり「プログラムと機能」スナップインのサービスと情報のバージョンの違いについて別途言及したいと思います。はい、リストは同じになりますが、バージョンが完全に混乱する可能性があります。見た目の観点からはあまり良くありませんが、すべてがスムーズに動作する限りはまったく問題ありません。たとえば、インストーラー サービスのバージョン番号は、隣接するバージョン番号より大幅に遅れています。恐怖と悪夢？いいえ、完全に再インストールされるのではなく、DLL が更新されるだけです。パッチ v9.5 U4 では、テクニカル サポートにとって悪夢のような事態が発生しました。更新中に、最も重要なサービスを除くすべてのサービスが新しいバージョンを受け取りました。パッチ U4b では、トランスポート サービスは他のすべてのサービスを XNUMX バージョンほど上回りました (数字から判断)。そして、それも問題ありません。重大なバグが見つかったため、他のものに比べてボーナスアップデートが行われました。つまり、まとめると、バージョンの違いは問題になる可能性がありますが、違いがあってもすべてが正常に動作するのであれば、おそらくそうであるはずです。しかし、テクニカル サポートに確認してもらうことを妨げる人はいません。

これらはいわゆる義務的奉仕であった。また、テープ サービス、マウント サービス、vPowerNFS サービスなど、補助的なサービスも多数あります。

Hyper-Vでは、一般的にはすべて同じですが、特定の Veeam バックアップ Hyper-V 統合サービス CBT を操作するための独自のドライバー。

最後に、バックアップ中に仮想マシンで作業する人について説明します。フリーズ前およびフリーズ後のスクリプトの実行、シャドウコピーの作成、メタデータの収集、SQLトランザクションログの操作などに使用されます。 Veeam ゲストヘルパー。そしてファイルシステムのインデックス作成が行われると、 Veeam ゲストインデクサー 。これらは、バックアップ中に展開され、その後削除される一時的なサービスです。

Linux マシンの場合、多数の組み込みライブラリとシステム自体の機能により、すべてがはるかに簡単になります。たとえば、インデックス作成は mlocate を通じて行われます。

今のところは以上です

もうこれ以上あなたを苦しめる勇気はない 簡単な Veeam の内部空間の紹介はこれで完了したと考えます。はい、私たちはまだログ自体に近づいていませんが、ログに提示される情報が支離滅裂な意識の流れのように見えないようにするために、このような導入は絶対に必要です。ログ自体については 3 番目の記事でのみ取り上げる予定です。次の記事では、ログを誰が生成するのか、ログには具体的に何が表示されるのか、そしてなぜ他の方法ではなくこの方法なのかについて説明する予定です。

出所： habr.com