In this episode, Sean Donahue is joined by Al Solorzano of E360 to discuss the worst disasters they've recovered from. Surprise twist, not all clouds are cumulonimbus and not all disasters are natural.<\/p><\/oembed>

Resources<\/p>

解决了

MS SQL Clusters - Multiple SCSI Controllers

  • 12 October 2016
  • 7 replies
  • 1602 views
A
Badge +4
嗨，我是我在Server 2012R2上创建一些MSCS SQL群集的过程。在适用的文档中，与Nutanix一起使用基于ISCSI的VG。另请阅读Mike Websters在即将发布的软件版本中与这些VG相关的HOT扩展与这些VG相关的磁盘的信息，真的很好！我的问题是关于我如何在当前多个VMware P/V SCSI控制器上破坏I/O。如果我遵循说明



https://portal.nutanix.com/#/page/solutions/details?targetId=BP-2049_Acropolis_Block_Services:BP-2049_Acropolis_Block_Services



Wouldn't all the I/O go over the default and only SCSI controller for that VM? I am trying to distribute the I/O for logs, tempDB, etc over multiple SCSI controllers. It was worked well in our environment in which we leverage RDMs and would like to try to repeat this on the Nutanix side. Can you let me know if this is feasable and the best way to achieve it.
icon

Best answer bymmcghee12 October 2016, 21:32

\n
\nWhen using iSCSI, storage traffic will go through the vNICs you have configured for the VM. From a performance perspective there are some cases where having muliple vNICs can help, like when CPU utilization is high due to a lot of IOPs. Multiple vNICs can help to balance the network operations across multiple cores. Enabling RSS helps with this but multiple vNICs can also have a benefit. If you have concerns you could add another vNIC and then balance the iSCSI sessions across the two.
\n
\nHTH,
\nMike","className":"post__content__best_answer"}">
View original
    This topic has been closed for comments

    7 replies

    mmcghee
    Rank
    Userlevel 3
    Badge +17
    Hi Adam,



    When using iSCSI, storage traffic will go through the vNICs you have configured for the VM. From a performance perspective there are some cases where having muliple vNICs can help, like when CPU utilization is high due to a lot of IOPs. Multiple vNICs can help to balance the network operations across multiple cores. Enabling RSS helps with this but multiple vNICs can also have a benefit. If you have concerns you could add another vNIC and then balance the iSCSI sessions across the two.



    hth，

    Mike

    \n

    \nWhen using iSCSI, storage traffic will go through the vNICs you have configured for the VM. From a performance perspective there are some cases where having muliple vNICs can help, like when CPU utilization is high due to a lot of IOPs. Multiple vNICs can help to balance the network operations across multiple cores. Enabling RSS helps with this but multiple vNICs can also have a benefit. If you have concerns you could add another vNIC and then balance the iSCSI sessions across the two.

    \n

    \nHTH,

    \nMike","quoteUsername":"mmcghee","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    Mikegelhar
    Userlevel 1
    Badge +9
    Are you presenting the Volume Group to the whole VMware cluster and then creating a datastore out of that or are you directly presenting the ABS Volume Group to the virtual SQL nodes? To replicate the IO separation you used with RDMs, you'll want to go with the option to create a datastore on the VMware cluster. This will let you can allocate multiple PVSCSI controllers and assign virtual disks to the VMs like you're used to for DBs, Logs, TempDB, etc.. Be sure to check VMware KB2038869查看您的网络配置是否需要ISCSI端口绑定。如果您有针对ISCSI流量与其他网络的单独的VLAN，则需要端口绑定。对于主机级别的冗余，您需要在每个主机中添加两个VMKernel端口，然后将每个端口中的每个端口绑定到物理NIC。VMware KB2045040explains the process.



    If you're mapping iSCSI directly from the VMs all the iSCSI configuration is all in the guest. Like  says, all the IO will be going through the NIC interface. Depending on your IP/VLAN setup you might use NIC teaming or MPIO. See this Microsoft blog for more infohere. Most likely you'll be using MPIO.



    无论哪种情况，Nutanix都使用AOS 4.7和使用“外部数据服务IP地址”使多路径变得非常容易。现在，您只需使用一个目标IP即可使用，Nutanix使用外部数据服务IP地址作为虚拟IP来自动管理ISCSI连接并在所有CVM上进行后端MPIO。



    Hopefully I wasn't too far off topic from your question and this info helps get you closer to what you're looking for.
    2038869 <\/a>to see if your network configuration requires iSCSI port binding. If you have separate VLANs for iSCSI traffic from other networks you'll need port binding. For redundancy at the host level, you'll want two vmkernel ports added to each host for iSCSI and then bind those each of those ports to a physical NIC. VMware KB 2045040<\/a> explains the process.

    \n

    \nIf you're mapping iSCSI directly from the VMs all the iSCSI configuration is all in the guest. Like \ufeff says, all the IO will be going through the NIC interface. Depending on your IP\/VLAN setup you might use NIC teaming or MPIO. See this Microsoft blog for more info     here<\/a>. Most likely you'll be using MPIO.

    \n

    \nIn either case, Nutanix has made multipathing incredibly easy with AOS 4.7 and the use of the \"external data services IP address\". Now you just have one target IP to use and Nutanix uses the external data services IP address as a virtual IP to automagically manage the iSCSI connections and backend MPIO across all CVMs.

    \n

    \nHopefully I wasn't too far off topic from your question and this info helps get you closer to what you're looking for.","quoteUsername":"mikegelhar","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    A
    Badge +4
    Mike(s)-

    Thanks so much for your responses, basically at this point on our POC cluster I am turning up both configurations to see what I can get the best performance out of and what is easiest from a managability perspective. If testing goes well (which I anticipate it will, move SQL workload over to some new nodes). Can either of you comment on what Nutanix finds as the sweet spot, the iSCSi mapping to the VMs, or presenting the volume groups and creating a datastore. I see pros/cons with both, curious if anyone could chime in on good/bad/ugly of both approaches.

    \nThanks so much for your responses, basically at this point on our POC cluster I am turning up both configurations to see what I can get the best performance out of and what is easiest from a managability perspective. If testing goes well (which I anticipate it will, move SQL workload over to some new nodes). Can either of you comment on what Nutanix finds as the sweet spot, the iSCSi mapping to the VMs, or presenting the volume groups and creating a datastore. I see pros\/cons with both, curious if anyone could chime in on good\/bad\/ugly of both approaches.","quoteUsername":"adamlw","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    Mikegelhar
    Userlevel 1
    Badge +9
    我的个人偏爱是使用数据存储在虚拟化层处保持存储分配的可见性，以监视工具，基于图像的备份和复制。

    今年早些时候，我在访客（单个VNIC）和基于数据存储的配置中进行了一些比较，发现数据存储配置总是更快。我的测试不是非常科学的，但这是一致的。

    \nEarlier this year I did some comparisons between in guest (single vNIC) and datastore based configurations and found the datastore config was always faster. My testing wasn't extremely scientific, but it was consistent.","quoteUsername":"mikegelhar","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    mmcghee
    Rank
    Userlevel 3
    Badge +17
    I may be misunderstanding but I thought the goal was to provide storage for a shared disk SQL/WSFC running within the VMs. Our supported method for this is using iSCSI directly to the VMs with ESXi. You wouldn't be able to create a shared disk cluster using a datastore (where you'd be better off using our standard NFS method) and we do not support RDMs today.
    Mikegelhar
    Userlevel 1
    Badge +9
    感谢您将我们重新回到...工作的配置也是一个关键考虑因素
    A
    Badge +4
    Yup, you are right Mike, sorry caught a little drift there. We actually do both WSFC and AGs so I will be exploring both options where applicable. Thank you both for your input - much appreciated.
    Terms & Conditions
    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