Veeam Log Diving 组件和词汇表

Veeam Log Diving 组件和词汇表

我们 Veeam 热爱日志。 由于我们的大多数解决方案都是模块化的,因此它们会写入大量日志。 由于我们活动的范围是确保您的数据安全(即安宁的睡眠),那么日志不仅应该记录每一个喷嚏,而且还应该做得更详细。 这是必要的,这样万一发生什么事情,就可以清楚地知道“什么”是如何发生的、谁应该受到责备以及下一步需要做什么。 这就像法医科学:你永远不知道什么小事可以帮助你找到杀害劳拉·帕尔默的凶手。

因此,我决定尝试一系列文章,依次讨论我们向日志写入的内容、将它们存储在哪里、如何不对其结构进行疯狂处理以及在其中查找什么内容。

为什么要写一系列文章,为什么不一次性描述所有内容呢?

简单地列出哪个日志在哪里以及其中存储了什么内容是一项相当灾难性的任务。 甚至想到保持这些信息的最新状态就让人感到害怕。 Veeam Backup & Replication 中所有可能的日志类型的简单列表是一张用小字体打印的表格。 是的,并且它仅在发布时相关,因为。 当下一个补丁发布时,可能会出现新的日志,旧日志中存储信息的逻辑会发生变化等。 因此,解释它们的结构和其中包含的信息的本质会更有利可图。 这将使您能够比死记硬背的平庸名字更好地导航这些地方。

因此,为了不急于一头扎进文本表的池子里,让我们在本文中做一些准备工作。 因此,今天我们不会深入讨论日志本身,而是远道而来:我们将编写一个术语表,并从生成日志的角度稍微讨论一下 Veeam 结构。

术语表和行话

在这里,首先值得向俄语纯洁性的捍卫者和奥热戈夫词典的见证人道歉。 我们都非常热爱我们的母语,但该死的 IT 行业却是用英语运作的。 好吧,这不是我们想出来的,但历史上确实发生过。 这不是我的错,是他自己来的 (c)

在我们的行业中,英语(和行话)问题有其自身的特点。 当在“主人”或“客人”这样天真无邪的词语下,整个世界早已明白了非常具体的事情时,那么在⅙的土地上,英勇的混乱和翻查字典的惊愕仍在继续。 以及严格强制性的论点“但是在我们的工作中......”。

另外,还有纯粹是我们的术语,这是 Veeam 产品固有的,尽管有些单词和短语已经掌握在人们手中。 因此,现在我们将就什么术语的含义达成一致,并且将来,在“客人”一词下,我将准确地指本章中所写的内容,而不是您在工作中习惯的内容。 是的,这不是我个人的心血来潮,这些都是业内公认的术语。 与他们战斗有些毫无意义。 尽管我总是赞成在评论中冷静下来。

不幸的是,我们的工作和产品中有很多术语,所以我不会尝试将它们全部列出。 只有关于海上生存的备份和日志的最基本和必要的信息。 有兴趣的朋友我也可以 推荐一篇文章 他还列出了与该部分功能相关的术语列表。

主持人(主持人): 在虚拟化领域,这是一台带有虚拟机管理程序的机器。 物理、虚拟、云——这些都不重要。 如果某个东西正在运行虚拟机管理程序(ESXi、Hyper-V、KVM 等),那么这个“东西”就称为主机。 无论是具有十个机架的集群,还是具有一个半虚拟机实验室的笔记本电脑 - 如果您启动了虚拟机管理程序,您就成为了主机。 因为虚拟机管理程序托管虚拟机。 甚至有这样一个故事,VMware 一度希望将主机一词与 ESXi 紧密地联系在一起。 但她没有。

在现代世界中,“主机”的概念实际上已经与“服务器”的概念融合在一起,这给通信带来了一些混乱,尤其是在 Windows 基础设施方面。 因此,任何托管我们感兴趣的服务的机器都可以安全地称为主机。 例如,在 WinSock 日志中,所有内容都标有单词“host”。 经典的“找不到主机”就是一个例子。 因此,我们从上下文开始,但请记住 - 在虚拟化世界中,主机是托管来宾的主机(下面两行将详细介绍这一点)。

从本地术语(在本例中甚至是缩写词)中可以看出,VMware 是 VI,vSphere 是 VC,Hyper-V 是 HV。

嘉宾(嘉宾): 虚拟机运行在主机上。 这里没什么好解释的,一切都是那么合乎逻辑、那么简单。 然而,许多人孜孜不倦地在这里引入了一些其他含义。

为了什么? 我不知道。
Guest OS,分别是客户机器的操作系统。 等等。

备份/复制作业(jobA): 纯粹的 Wim 行话,表示一些任务。 备份作业==备份作业。 没有人知道如何将其漂亮地翻译成俄语,所以每个人都说“JobA”。 强调最后一个音节。

是的,他们只是接过它并说“joba”。 即使在信中他们也这样写,一切都很好。
各种备份作业、备份任务等,谢谢,但不需要。 只要一份工作,你就会被理解。 最重要的是把重音放在最后一个音节上。

备份(备份,备份。对于true-oldfags,允许备份): 除了明显的(位于某处的数据的备份副本)之外,它还意味着作业本身(上面三行,如果您已经忘记了),因此会出现备份文件。 也许,以英语为母语的先生们懒得说我每次都运行了我的备份工作,所以他们只是说我运行了我的备份,每个人都完全理解对方。 我邀请您支持这项精彩的倡议。

合并(合并): ESXi 5.0 中出现的术语 快照菜单中的一个选项,用于启动删除所谓的孤立快照的过程。 也就是说,物理上可用但不符合显示的逻辑结构的快照。 理论上,此过程不应影响快照管理器中显示的文件,但任何事情都可能发生。 整合过程的本质是将快照(子盘)中的数据写入主(父)盘。 组合磁盘的过程称为合并。 如果已发出合并命令,则可以在合并和删除快照之前从数据库中删除快照记录。 如果由于任何原因无法删除快照,则会出现这些相同的孤立快照。 关于使用快照,VMware 好知识库。 我们也以某种方式了解他们 写在哈布雷.

数据存储(Stora 或存储):  一个非常广泛的概念,但在虚拟化领域,它被理解为存储虚拟机文件的地方。 但无论如何,在这里你需要非常清楚地理解上下文,并且毫无疑问地澄清你的对话者到底在想什么。 

代理(代理): 重要的是要立即了解 Veeam Proxy 与我们在互联网上习惯的不太一样。 在 Veeam 产品中,这是一种处理将数据从一个地方传输到另一个地方的实体。 如果不详细说明,那么 VBR 是一个命令和控制服务器,代理是它的主力。 也就是说,代理是流量流经的机器,其上安装了有助于管理此流量的 VBR 组件。 例如,将数据从一个通道传输到另一个通道,或者只是将磁盘固定在其自身上(热添加模式)。

存储库(存储库):  从技术上讲,这只是 VBR 数据库中的一个条目,指示存储备份的位置以及如何连接到该位置。 事实上,它可以只是一个 CIFS 球,也可以是云中的单独磁盘、服务器或存储桶。 同样,我们处于上下文中,但我们知道存储库只是备份所在的位置。

 快照(SnapshOt): 牛津语法爱好者更喜欢说谁是快照,谁是快照,但大多数文盲受益于更大的质量。 如果有人不知道,这是一项允许您恢复磁盘在某个时间点的状态的技术。 这是通过暂时将 I/O 操作从主磁盘重定向到远离主磁盘来完成的 - 那么它将被称为 RoW(写入时重定向)快照 - 或者通过将可重写块从磁盘移动到另一个磁盘 - 这将被称为 CoW(写入时复制) )快照。 正是由于使用这些功能的广泛可能性,Veeam 才能发挥其备份魔力。 严格来说,不仅是他们,而且是接下来的版本的问题。

ESXi 文档和日志中围绕该术语存在混乱,在提及快照的上下文中,您可以找到快照本身、重做日志,甚至增量磁盘。 Veeam文档中不包含这样的撕裂,快照就是快照,重做日志正是独立非持久磁盘创建的REDO文件。 当虚拟机关闭时,REDO 文件会被删除,因此将它们与快照混淆会导致失败。

合成(合成): 合成备份是反向增量备份和永远正向备份。 如果您还没有遇到过这个术语,它只是用于构建备份链转换的机制之一。 但是,在日志中您还可以找到 Transform 的概念,它用于从增量创建完整副本(合成完整)的框架中。

任务(任务): 这是处理作业中每台机器的过程。 那就是:你有一个备份作业,其中包括三台机器。 这意味着每辆车都将作为单独任务的一部分进行处理。 总共有四份日志:主要一份用于作业,三份用于任务。 然而,这里有一个重要的细微差别:随着时间的推移,“任务”这个词已经变得不必要地含糊不清。 当我们谈论一般日志时,我们的意思是任务就是一个虚拟机。 但代理和存储库上都有“任务”。 在那里,它可以指虚拟磁盘、虚拟机和整个作业。 也就是说,重要的是不要失去上下文。

Veeam%name% 服务:  为了成功备份,多项服务同时工作,可以在标准设备中找到其中的列表。 它们的名称相当透明地反映了它们的本质,但在同类产品中,有最重要的一个 - Veeam Backup Service,没有它,其余的都将无法工作。

VSS: 从技术上讲,VSS 应始终代表 Microsoft 卷影复制服务。 事实上,它被许多人用作应用程序感知图像处理的同义词。 当然,这绝对是错误的,但这是一个来自“任何 SUV 都可以称为吉普车,你会理解的”类别的故事。

神奇的原木和它们居住的地方

我想通过揭示一个伟大的秘密来开始本章:日志中显示的时间是什么?

记得:

  • ESXi 始终以 UTC+0 写入日志。
  • vCenter 根据其时区的时间保存日志。
  • Veeam 按其所在服务器的时间和时区保存日志。
  • 只有 EVTX 格式的 Windows 事件才不会受到与任何内容绑定的影响。 打开后,将重新计算打开它们的车辆的时间。 这是最方便的选择,尽管有一些困难。 唯一明显的困难是区域设置的差异。 这是一条实际上有保证的通往不可读日志的路径。 是的,有多种处理方法,但我们不要争论 IT 中的所有内容都以英语运行的事实,并同意始终在服务器上设置英语区域设置。 哦拜托。 

现在我们来谈谈日志所在的地方以及如何获取它们。 对于VBR,有两种方法。 

如果您不急于在常规堆中查找与您的问题特别相关的文件,那么第一个选项是合适的。 为此,我们有一个单独的向导,您可以在其中指定特定作业以及需要日志的特定时间段。 然后他会亲自检查文件夹并将您需要的所有内容放入一个存档中。 在哪里寻找它以及如何使用它在中详细描述 这个高频.

但是,向导不会收集所有任务的日志,例如,如果您需要研究恢复、故障转移或故障恢复的日志,您的路径位于文件夹中 %ProgramData%/Veeam/备份。 这是主要的 VBR 徽标存储区,%ProgramData% 是一个隐藏文件夹,这很好。 顺便说一句,可以使用 HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication 分支中的 REG_SZ: LogDirectory 类型注册表项重新分配默认位置。

在 Linux 计算机上,应在 / 中查找工作代理日志var/log/VeeamBackup/如果使用 root 或 sudo 帐户。 如果您没有此类权限,请查找登录 /tmp/VeeamBackup

对于 %OS_name% 日志的 Veeam 代理,应在以下位置搜索 %ProgramData%/Veeam/端点%ProgramData%/Veeam/备份/端点)和 /var/日志/veeam 分别

如果您正在使用应用程序感知图像处理(很可能您正在使用),那么情况会变得更加复杂。 您将需要我们的帮助程序的日志(存储在虚拟机本身内部)以及 VSS 日志。 关于如何以及在哪里获得这种幸福,在《圣经》中有详细的记载。 本文。 当然还有 单独的文章 收集必要的系统日志。 

Windows事件可以根据以下方式方便地收集 这个高频。 如果您使用 Hyper-V,事情会变得更加复杂,因为您还需要应用程序和服务日志 > Microsoft > Windows 分支中的所有日志。 尽管您总是可以采用更愚蠢的方法,只从 %SystemRoot%System32winevtLogs 中获取所有对象。

如果安装/升级过程中出现问题,您需要的所有内容都可以在 %ProgramData%/Veeam/Setup/Temp 文件夹中找到。 尽管我不会隐瞒这样一个事实,即在操作系统事件中您可以找到比这些日志更有用的信息。 剩下的有趣的地方在于%Temp%,不过主要是相关软件的安装日志,比如base、.Net库之类的东西。 请注意,Veeam 是从 msi 安装的,其所有组件也作为单独的 msi 软件包安装,即使 GUI 中未显示这一点。 因此,如果其中一个组件安装失败,整个VBR安装将停止。 因此,您需要查看日志并查看到底发生了什么以及发生在什么时间点。

最后,一个生活技巧:如果您在安装过程中收到错误,不要急于单击“确定”。 首先我们获取日志,然后单击“确定”。 这样您将获得在错误发生时结束的日志,末尾没有垃圾。

您恰好需要进入 vSphere 日志。 这种职业是非常忘恩负义的,但是,卷起袖子,就必须做点别的事情。 在最简单的版本中,我们需要包含虚拟机事件 vmware.log 的日志,该日志位于其 .vmx 文件旁边。 在更困难的情况下,请打开 Google 并询问您的主机版本的日志位于何处,因为 VMware 喜欢在不同版本之间更改此位置。 例如, 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。 事情就这样发生了:我们放置了另一个应用程序 - 另一个数据库出现了。 为了不把所有的鸡蛋都放在一个篮子里。

但为了让所有这些经济顺利运转,我们需要一套将所有组件连接在一起的服务和应用程序。 举个例子,这就是我的一个实验室的样子:

Veeam Log Diving 组件和词汇表
担任首席指挥 Veeam 备份服务。 负责与基地交换信息的就是他。 他还负责启动所有任务,协调分配的资源,并作为各种控制台、代理和其他一切的通信中心。 总而言之,没有他肯定没有办法,但这并不代表一切都是他亲力亲为。

帮助他实现他的计划 Veeam 备份管理器。 这不是一个服务,而是一个启动作业并监视其执行过程的实体。 备份服务的工作人员,通过它连接到主机、创建快照、监视保留等。

但回到服务列表。 Veeam 经纪服务。 出现在 v9.5 中(这不是加密货币矿工,正如一些人当时认为的那样)。 收集有关 VMware 主机的信息并维护其相关性。 但不要立即跑去写愤怒的评论,说我们正在监视你,并将所有登录名/密码泄露给塔施少校。 一切都变得简单一些。 当您运行备份时,您需要做的第一件事是连接到主机并更新有关其结构的所有数据。 这是一个相当缓慢且繁琐的故事。 只需记住您通过 Web 界面登录需要多长时间,并记住那里只计算顶层。 顺便说一句,然后您仍然需要将整个层次结构打开到正确的位置。 一句话,恐怖。 如果您运行十几个备份,则每个作业都需要执行此过程。 如果我们谈论的是大型基础设施,那么这个过程可能需要十分钟或更长时间。 因此,决定为此分配一个单独的服务,通过该服务可以始终接收最新的信息。 启动时,它会检查并扫描所有添加的基础设施,然后尝试仅在增量更改级别上工作。 因此,即使您同时运行一百个备份,它们都会向我们的代理请求信息,并且不会用它们的请求来折磨主机。 如果你担心资源问题,那么根据我们的计算,5000个虚拟机只需要大约100Mb的内存。

接下来我们有 Veeam 控制台。 他是Veeam远程控制台,他是Veeam.Backup.Shell。 这与我们在屏幕截图中看到的 GUI 相同。 一切都简单明了 - 控制台可以从任何地方启动,只要它是 Windows 并且有到 VBR 服务器的连接。 唯一可以说的是,FLR 进程将在本地挂载点(即在运行控制台的计算机上)。 嗯,各种 Veeam Explorer 也将在本地运行,因为它们是控制台的一部分。 但它已经把我带入了荒野......

另一个有趣的服务是 Veeam 备份目录数据服务。 在服务列表中称为 Veeam Guest Catalog Service。 他致力于对来宾计算机上的文件系统进行索引,并用这些知识填充 VBRCatalog 文件夹。 它仅在启用索引复选框的情况下使用。 仅当您有企业管理器时启用它才有意义。 因此,我发自内心的建议:如果你没有EAT,就不要像这样打开索引。 节省您的紧张和支持时间。

其他重要服务也值得注意 Veeam安装程序服务,在其帮助下,必要的组件被交付并安装在代理、存储库和其他网关上。 事实上,它将必要的 .msi 软件包带到服务器并安装它们。 

Veeam 数据移动器 - 在代理(不仅是)上启动的辅助代理的帮助下,它正在转移数据。 例如,备份时,一个代理将从主机数据存储中读取文件,第二个代理将仔细地将它们写入备份。

另外,我想指出客户经常反应的一件重要事情 - 这就是程序和功能管理单元中的服务和信息版本的差异。 是的,列表是相同的,但版本可能完全不一致。 从视觉角度来看,这并不是很酷,但如果一切稳定的话,那就完全正常了。 例如,对于Installer服务,版本号远远落后于邻近的版本号。 恐怖和噩梦? 不会,因为它没有完全重新安装,只是更新了它的 DLL。 在补丁 v9.5 U4 中,发生了一场技术支持噩梦:在更新过程中,除了最重要的服务之外,所有服务都收到了新版本。 在 U4b 补丁中,传输服务超过了所有其他服务多达两个版本(从数字来看)。 这也是正常的——其中发现了一个严重的错误,因此它相对于其他版本获得了额外的更新。 总结一下:版本差异可能是一个问题,但如果存在差异并且一切正常,那么它可能应该是一个问题。 但没有人禁止你在技术支持中澄清这一点。

这些就是所谓的强制性或强制服务。 还有一大堆辅助服务,例如磁带服务、挂载服务、vPowerNFS 服务等。

对于 Hyper-V,一般来说,一切都是一样的,只是有一个特定的 Veeam Backup Hyper-V 集成服务 以及您自己的用于使用 CBT 的驱动程序。

最后,我们来谈谈备份期间谁在虚拟机上工作。 运行冻结前和冻结后脚本、创建卷影副本、收集元数据、使用 SQL 事务日志等。 Veeam 访客助手。 如果文件系统被索引, Veeam 访客索引器 。 这些是在备份期间部署并在备份后删除的临时服务。

对于Linux机器来说,由于存在大量内置库和系统本身的功能,一切都变得简单得多。 例如,索引是通过mlocate完成的。

目前为止就这样了

我不敢再伤害你 简要 我认为 Veeam 发动机舱的介绍就结束了。 是的,我们甚至还没有接近过这些巢穴本身,但是相信我,为了让其中呈现的信息看起来不像是不连贯的意识流,这样的介绍是绝对必要的。 我计划仅在第三篇文章中讨论日志本身,下一篇文章的计划是解释谁生成日志、日志中到底显示什么以及到底为什么,而不是其他。

来源: habr.com

添加评论