新VM的默认保护组

  • 2014年2月17日
  • 8个答复
  • 1489次观点
Shuguet
Userlevel 4
徽章 +20
你好，

有没有办法（除了休息或脚本/crontab）将容器中创建的任何新VM放在“默认”保护域中？

基本原理是为诸如诸如“此群集”之类的所有VM的“标准”策略创建一个“标准”策略，默认情况下每2H复制一次每2H复制”，那么，如果需要处理异常，则可以根据情况对其进行处理。

我有一个顾客，它正在努力，目的是从NetApp/NFS/IBM叶片解决方案转移到Nutanix，如果一切顺利。
问题是，他们使用SnapMirror每1H复制其数据存储（群集1）。他们确实希望能够仅复制VM，但是他们不想将每个新的VM单独添加到保护域。

西尔万。
Sylvain Huguet -2X Nutanix技术冠军2015-2016，法国Nutanix Connect Chapter Champion，法国VMUG领导者，6倍VMware Vexpert 2011至2016
    \n
    \nIs there a way (other than REST or scripting\/crontab) to put any new VM created inside a container to a \"default\" protection domain?
    \n
    \nThe rationale is to create a \"standard\" policy for all VMs of a cluster like \"this cluster is replicated every 2h, by default\", then if exceptions need to be handled, they can be treated on a case by case basis.
    \n
    \nI have a customer that is PoCing Nutanix, with the goal to move from a NetApp\/NFS\/IBM Blades solution to Nutanix if everything goes well.
    \nProblem is, they use SnapMirror to replicate their datastore (1 by cluster) every 1h. They do want to be able to replicate just a VM, but they don't want to have to add each new VM individually to a protection domain.
    \n
    \nSylvain.","quoteUsername":"shuguet","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

    8个答复

    dlink7
    Userlevel 4
    徽章 +19
    就在今天的脚本上。不过，您的问题是，您是否想要每个容器或集群级别的默认保护域集？还是群集应该有默认设置，然后容器过度超过全局设置？
    Shuguet
    Userlevel 4
    徽章 +20
    最低限度应在容器级别。
    我们创建VM的频率要比创建容器要多得多。

    如果可以为群集定义默认值，然后在容器级别上覆盖它，但是我还可以为群集的每个新容器设置默认保护组...

    无论如何，由于容器需要复制到另一个容器，因此这没有很多意义，不是吗？群集如何自动确定网站A上的哪个容器转到站点B上的哪个容器？

    西尔万。
    Sylvain Huguet -2X Nutanix技术冠军2015-2016，法国Nutanix Connect Chapter Champion，法国VMUG领导者，6倍VMware Vexpert 2011至2016
    \nWe create VM far more often than we create containers.
    \n
    \nIf it's possible to define a default for a cluster then override it at the container level, fine, but I can also set the default protection group for each new container of the cluster...
    \n
    \nAnyway, as a container needs to replicate to another container, this doesn't make a lot of sense, no? How would the cluster be able to automaticaly decide which container on site A goes to which container on site B?
    \n
    \nSylvain.","quoteUsername":"shuguet","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    dlink7
    Userlevel 4
    徽章 +19
    不需要容器到容器复制，所有这些都必须在生产域级别上向上站点，您可以将VM放在一个容器中，该容器被复制到不同的站点。
    Shuguet
    Userlevel 4
    徽章 +20
    我不知道我是否正确理解您的帖子，但是如果您的意思是必须在保护域级别进行设置，则是的。
    在这种情况下，我的想法是将默认保护域分配给群集或容器中创建的所有新VM。
    这样，您可以一次配置保护域设置（例如复制频率），然后让所有新的VM继承这些设置。
    如果您需要VM的特定设置，则仍然可以为此VM分配另一个保护域并有效地覆盖默认设置。

    就我而言，由于我们每小时从网站1上的群集A到站点2的群集B复制所有VM，因此我们将被覆盖。
    在未来的Futur中，如果我们创建不需要复制的VM（例如vshield Agent VM for Supemple），则可以为这些VM创建一个特定的容器，或者将它们排除在保护域中并实现所需的结果。

    西尔万。
    Sylvain Huguet -2X Nutanix技术冠军2015-2016，法国Nutanix Connect Chapter Champion，法国VMUG领导者，6倍VMware Vexpert 2011至2016
    \nMy idea in this case would be to have a default protection domain assigned to all new VMs created in the cluster or container.
    \nThat way, you can configure the protection domain settings once (like replication frequency) and then have all new VMs inherit these settings.
    \nIf you need specific settings for a VM, you would still have the ability to assign another protection domain to this VM and effectivly override the default settings.
    \n
    \nIn my case, as we are replicating all VMs every hour from cluster A on site 1 to cluster B on site 2, we would be covered.
    \nIn the futur if we create VMs that does not need replication (like vShield agent VM for exemple), we could either create a specific container for these VMs, or exclude them from the protection domain and achieve the desired result.
    \n
    \nSylvain.","quoteUsername":"shuguet","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    dlink7
    Userlevel 4
    徽章 +19
    使用NOS 4.0和PowerShell，您可以自动化此功能

    http://itbloodpressure.com/2014/04/17/nos-4-0-powershell-add-add-all-your-your-vms-vms-to-a-protection-domain/
    \n
    \nhttp:\/\/itbloodpressure.com\/2014\/04\/17\/nos-4-0-powershell-add-all-your-vms-to-a-protection-domain\/","quoteUsername":"dlink7","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    Shuguet
    Userlevel 4
    徽章 +20
    很棒的解决方案！

    我建议一个也应该有效的衬里。
    我还不能测试它

    但是，我仍然希望在Nutanix群集级别上真正集成某些东西，而不是从外部进行自动/精心策划。
    问题是，这个解决方案真的很整洁，但是我仍然会依靠一个必须监视甚至升级的脚本。
    另一个动人的作品。

    我有此请求的客户已经管理了更多4200 VM，并且在未来两年内可能会翻一番。默认情况下将其集成在一起确实会很有帮助。

    西尔万。
    Sylvain Huguet -2X Nutanix技术冠军2015-2016，法国Nutanix Connect Chapter Champion，法国VMUG领导者，6倍VMware Vexpert 2011至2016
    \n
    \nI suggested a one liner that should work, too.
    \nI cannot test it (yet) but I plan to as soon as I upgrade to NOS4.0
    \n
    \nBut still, I would like something realy integrated at the Nutanix Cluster level, rather than automated\/orchestrated from the outside.
    \nThe thing is, this solution is really neat, but I will still depend on a script, that has to be monitored, and maybe upgraded.
    \nAnother moving piece.
    \n
    \nMy client that had this request already manage more that 4200 VMs, and they may double that number in the next 2 years. Having this integrated by default would really be helpful here.
    \n
    \nSylvain.","quoteUsername":"shuguet","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    t
    秩
    UserLevel 2
    徽章 +13
    大家好，我解决这个问题的任何解决方案，我有一个客户询问它。

    谢谢，
    托尼
    \n
    \nThanks,
    \nTony","quoteUsername":"tonyholland00","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    C
    徽章 +5
    能够将保护/SLA详细信息直接分配给群集或存储容器是很酷的 - 一种与基础结构查看/互动的另一种方法

    回复


    条款和条件
    Learn more about our cookies.<\/a>","cookiepolicy.button":"Accept cookies","cookiepolicy.button.deny":"Deny all","cookiepolicy.link":"Cookie settings","cookiepolicy.modal.title":"Cookie settings","cookiepolicy.modal.content":"We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.<\/a>","cookiepolicy.modal.level1":"Basic
    Functional","cookiepolicy.modal.level2":"Normal
    Functional + analytics","cookiepolicy.modal.level3":"Complete
    Functional + analytics + social media + embedded videos"}}}">
    Baidu