详细介绍:怎么使用清单中的‘设备’和‘设备ID’选项, 他们是怎么工作的

Version 11

    .

     

     

    0 - I介绍:

     

    很多用户对配置>服务>清单,界面上的‘设备’和‘设备ID’按钮很迷茫或者知道但没有把握. 最常见的误解是他们只是看起来不同,但是做的是同样的事情。

     

    事实并非如此。

     

    这篇文档的目的是从概念上阐明相关的技术是如何工作的,并且他们是怎么形成的。所以提供了一个易于理解的环境,来引导读者更加清楚这两个按钮在这里提供的功能。

     

    声明,截屏中包含了一些标志,是为了更清晰地表示出我们正在讨论的是哪个部分。

    Cfg_Svc_Inc_EDIT.JPG

    (1) -- 关于‘管理重复项’

    (2) -- 关于检测/删除重复设备条目

    .

    I - 重复设备ID

     

    I.A - 这是什么?

    这是历史上三大最古老的工作之一

     

    这个技术源于OSD (操作系统部署) - 甚至是OSD技术出现在LANDesk之前 - 是一个特别的场景。 这个特别的场景如下:(所有的点都必须满足):
    - 当你克隆了一个系统镜像 (i.e. 拷贝了一个设备的镜像,这个镜像没有事先做SYSPREP操作, 没有改变, 直接拷贝到其他的设备上).
    - 带着LANDesk的代理做在镜像上.
    - 没有移除这个镜像中的代理里面的LANDesk设备ID.

     

    Thus, for example:

    If you had - say - 100 devices, this would result in 100 devices all reporting one and the same LANDesk Device ID (the way by which we uniquely identify a device), thus their inventory scans would continuously overwrite each other.

     


    I.B - How & When does it work?

    这一段技术工作是由清单扫描完成的。

     

    清单服务检查属性,默认的(基于很长时间的经验积累,我们设置了这样的默认值)是使用网卡地址+设备名称。

     

    现在,当一个清单扫描执行的时候,核心服务器会依据下面的逻辑检查:
    ""
    - 我是否已经存储了这个设备的ID?
    - 如果设备ID已经存在,网卡地址是否不同?设备名称是否不同?
    ""

     

    最后一部分,基于设置的值,默认我们默认检查这两个属性,如果都不同,  (因为我们已经在数据库中查到了一个一模一样的设备ID,但是网卡地址和设备名称不同,很大程度上,这意味着一个物理上完全不同的机器。) 请看下面的截屏,我们是这样设置默认值的:

     

    Duplicate_Devices.JPG

     

     

    I.C - 打破设置

    这个截屏能更清晰的让我们明白,所有相关设置的含义。在后面,我们设置了不同的值,来明白不同设置会有什么样不同的行为,那样会比较有帮助。

     

    Duplicate_Devices_EDIT.JPG

    #1 - 属性列表:

    这个列表,显示了清单中的所有已经有的值,(你能在创建LD-查询中看到类似的结构)。 这个是一个可能得到的属性的属性池。我们可以从这里选择出,哪个值来作为我们的唯一标识出一台设备。

     

     

    #2 - I标识属性dentity Attributes:

    这个模块包含了可用的属性,这里的属性用来表明怎么明确一台设备是‘唯一’的。

     

    注意,这些属性必须要是常量,不能是变量。如,网卡地址,设备名这样的不会换的,但是像一些与时间戳或者软件相关的属性就不是太好。

     

    强烈建议这里最少用两个属性(因为机器有可能会变更设备名称,或者网卡坏了,换了一个另外的地址). 但是,使用一个属性也比用太多属性要好。我们不推荐用4个以上的属性。

     

    最后一个建议,是为了性能考虑。太多的属性意味着在清单扫描时,产生更多的数据库的交互, 会指数的增长。

     

    在大多数环境中,默认的我们建议的配置是足够用的。(多年的经验). 在改变这个设置之前,务必要深思熟虑。

     

    这里如果设置不好,会因为很多清单的相关问题。

     

    #3 - 重复设备ID的触发:

    从列表中选择的属性, (#2 - 标识属性), 这个模块带 # 的属性,是用来“触发”清单扫描上来的设备中的重复设备的.

     

    实际上 -- 默认的配置中,这意味着两个属性同时 (只有2个属性能被选择) 为不同的值 (同时,设备唯一值是相同的),对于核心服务器来说,就是检测到了一个清单扫描上来的重复设备,实际上是一个不同的设备。

     

    这里有一个假设的例子:

     

    一个核心服务器有一个客户端设备在数据库中的值如下:

    - 唯一值 -- {12345678-1234-1234-1234-123456789012}

    - 设备名 -- NormalHost

    - 网卡地址 -- 00-00-00-00-00-00-00-00

     

    这时,一台设备发送下面的信息到核心服务器:

    - 唯一ID -- {12345678-1234-1234-1234-123456789012}

    - 设备名 -- DifferentHost

    - 网卡地址 -- 11-11-11-11-11-11-11-11

     

    核心服务器会注意到下面的事情:

    1 - 唯一值是已经存在数据库中的 (那么核心服务器会试图重写/更新这个已经存在的记录,而不是创建一条新的记录)。

    2 - 核心服务器注意到,设备名是不同的 ("NormalHost" 和 "DifferentHost")。

    3 - 核心服务器注意到,网卡地址是不同的 (all 00-s vs all 11-s)。

     

    4 - 由于唯一值是相同的 (所以我们试图更新已经存在的记录)但是我们定义的活动属性,来检测是否重复设备的值,都是不通同的。 那么接下来会发生的事情是什么呢,我们会在下面的模块中解释。 (在模块编号 I.D中).

     

    #4 - 拒绝重复设备:

    这个是一个‘开关’,用来判断是拒绝一个重复设备ID'(这是推荐的) 或者是让这种重复设备ID就这么存在。 -- 如果我们选择,就让这种重复的设备ID就这么存在,那么,我们会在清单扫描的时候重写数据库,用第2条、第3条、第4条等等的新数据来重写这条数据。

     

     

    I.D - 假设我们发现了一条重复设备ID,接下来会发生什么呢?

    假设我们发现了一个重复设备ID,我们立刻会拒绝这个清单扫描文件。然后将这个设备ID记录为‘损坏的’。

     

    基于这样的观点,当任何一个客户端试图发送一条清单扫描数据,而且设备ID的值是已经存在的。那么这台报告重复设备ID的客户端会被告知,它需要生成一个新的设备ID。因为不能表明谁才是这个ID的正确拥有者,安全起见,我们会要求每一个用这个重复ID的客户端设备去生成一个新的ID, 全都随机生成这个唯一值。

     

    那么接下来,修复这个问题,强制所有拥有这个重复ID的客户端来生成一个随机的唯一值。鉴于这些设备ID是从windows的SID来成形的,所以生成的ID仍然是重复的值的几率是非常小的。 (即使又生成了一个重复ID,这样的客户端设备很快又被告知去生成一个新的ID, 随机生成这个唯一值)。


    I.E -- 最后需要注意的

    这个技术只需要在遇到这种情景的时候用到。只有在你遇到了重复设备ID的时候才有用到这个技术这种可能性。

     

    这个技术的关键是修复重复设备ID, 这样维护来让设备之间不会互相的重复写入。

     

    重点是,如果是地址的问题 - 你就会有很多的明明是一个设备,却出现了很多的条目在数据库的清单数据表中 (重复的设备的条目,来防止重复的设备ID)。

     

    =======================================
    =======================================

     

    另外的选项,需要分成两个模块。我们会从讲过的内容上来再看一次,来加深理解。

     

    =======================================
    =======================================

     

    II - 重复设备

    Choose_OR_or_AND_EDIT.JPG


    II.A - 这是什么?

    这是在数据库维护中运行的,不是实时更新的.

     

    关键的问题是,“移除重复设备,当……“这个对话框表明了,两个可能。A或者B,或者这两个同时。

     

    这里没有一个”正确“的方法。这是基于环境的。下面来看一下是如何工作的。

     


    II.B - 如何工作?

    清单服务查看了数据库的维护,检查了重复的项目。四个可能性(与、或):

     

    II.B.1 - 这个只发生在设备名
    II.B.2 - 这个只发生在网卡地址
    II.B.3 - 这个只发生在当‘设备名或者网卡地址其中一个符合’的情况

    MAC_or_DEVICES_EDIT.JPG

     

     

    II.B.4 - 这个只发生在设备名和网卡地址都符合的情况

    MAC_and_DEVICES_EDIT2.JPG

     

    这个重复的的设备就会被从数据库中删除,没有防护措施来阻止这个重复设备再次出现,只是删除掉了。

     


    II.C -- 最后要注意的

    最后的说明,这个不是一个实时生效的设置。在 III这个部分我们会再次强调。

     

    这是一个依据I这个部分的逻辑开发的功能,是因为发现了有的客户不得不手动删除一些重复的设备,所以开发了自动来做这件事的功能。

     

    ====================================
    ====================================

     

     

    III - 重复设备 - 恢复旧的设备ID

    MAC_and_DEVICES_EDIT.JPG


    III.A - 这是什么?

    恢复旧设备ID,这个功能 - 这是从模块 II延伸过来的开发的一个功能.

     

    比起每天晚上我们没完没了的删除重复设备,不如在数据写入数据库之前试着阻止这种情况的发生。

     

    "恢复旧设备ID"的工作是一个模块II的延伸。在同样的地方我们有自己的设置。

     

    基于’删除重复设备‘的进程,这个功能是发生在清单扫描文件传回的时候,这个基本上是实时发生的了。

     


    III.B - 是如何工作的?

    这是基于如何定义’重复设备‘的。 (参考模块II.B), 恢复旧设备ID是同样的逻辑。

     

    当清单文件来的时候,使用了同样的逻辑 (模块II.B.1 到 II.B.4)来删除这个设备,是同样的设备的清单,但是和数据库中是不同的设备ID。

     

    常见的情景是,如果你从一个干净的镜像恢复,硬件信息是同样的,但是设备名是或者不是相同的- 但是LANDesk设备ID一般是不同的 (除非你用了LANDesk的镜像部署,并且做了Sysprep,这样我们才会生成一个已经存在的DeviceID)。

     


    III.C - 假设我们发现了一个重复设备,会发生什么?

    清单扫描会拒绝,客户端会收到信息’用你自己的旧设备ID‘. 当客户端采用了旧的设备ID, 很有可能,就会采用了一个已经存在数据库中的条目。

    这个大致会需要2-3次清单扫描来填充必要的信息。

     

    当客户端用了旧的设备ID,清单扫描就会正常了。

     


    III.D - 最后的最后的要注意的

    恢复到旧的设备ID这个选项是很好的,很有效的防止重复设备的第一道防线。

    一个现实的,普遍的问题是,该怎么来设置呢。

     

    "通常情况", 设备名和网卡地址是会比较正常的。但是,当你在一个环境中,设备经常会会重新取得一个新的设备名,那么这个逻辑是就不能正常工作了。

     

    总之,当你用到’或‘的逻辑的时候,有可能会出问题。譬如系统会在某个属性挂起。其中一个常见的问题,就是,网卡地址是虚拟机的。

     

    虚拟机总是有个随机的小地址池,如果你有两台设备,共享一个(如网卡地址),那么这也会造成后面的问题。

     

    =======================================
    =======================================

     

    IV - 结论

    这篇文章帮助我们解释了重复设备ID和重复设备的区别。所有的概念和设置基本都覆盖了。

     

     

    英文链接:

    http://community.landesk.com/support/docs/DOC-22423