我有一台Win2008R2服务器和一台Synology NAS。 在Nas上，有6个iSCSI分区安装在Windows服务器上。 Windows服务器在Hyper-V下被虚拟化。 重新启动客户机后，6个分区中的两个不重新挂载，我不得不手动重新挂载它们…每一次。 每个人都有类似的configuration，并已configurationCHAP身份validation。 所有6个都出现在collections夹列表中。 事件日志显示没有关于iSCSI的错误。 其他4个分区挂载没有问题。 任何build议进一步debugging？ 编辑：在与Synology交谈之后，他们build议禁用chap身份validation并启用一个名为masking的function，这基本上是一个filter，用于阻止哪些节点可以连接到每个LUN。 这对问题产生了巨大的影响。 在断电或类似事件之后，它仍会每隔一段时间发生一次，但在重新启动之后，我几乎可以确定这个连接将被重新安装。 我猜想它是在iscsi发起者和authentication协商中的目标之间的一个问题。
iSCSI目标 具有16 GB RAM和16核CPU的Ubuntu 14.04 （Trusty Tahr）作为LVM支持的iSCSI目标，使用三个三星SSD磁盘，每个SSD都可以使用具有板载高速caching的LSI 6 Gbit / s控制器执行65k IOPS。 目标SSD盘上的基准： fio –filename=/dev/sdd –direct=1 –sync=1 –rw=write –bs=4k –numjobs=10 –iodepth=1 –runtime=60 –time_based –group_reporting –name=ssd-max iops=65514 其中sdd使用三个三星850 EVO固态硬盘在硬件RAID 0中进行configuration。 引发剂 我在Ubuntu 14.04客户端上导出了一个500G的LUN，内存为32GB RAM和8个核心CPU。 对导出的LUN进行基准testing fio –filename=/dev/sdg –direct=1 –sync=1 –rw=write –bs=4k –numjobs=10 –iodepth=1 –runtime=60 –time_based –group_reporting –name=client-max iops=2400 在做DAS和networking时，性能会有明显的下降，我预计至less有10k IOPS。 目标和发起者之间的通信小于1 ms，iperf显示9.2 Gbit / s的networking吞吐量。 据我所知，4k写入会对性能产生影响，因为在写入磁盘之前，每个数据都必须经过启动器和目标的networking堆栈，但这是从65k到2k的不可接受的下降。 […]
我有一对ProCurve 2810-24G，我将使用Dell Equallogic SAN和Vmware ESXi。 由于ESXi执行MPIO，所以我对交换机之间的链路configuration有些不确定。 中继线是交换机之间的正确途径吗？ 我知道SAN和ESXi主机的端口应该是untagged的，那么这是否意味着我希望在中继端口上标记VLAN？ 这或多或less是这样的configuration： trunk 1-4 Trk1 Trunk snmp-server community "public" Unrestricted vlan 1 name "DEFAULT_VLAN" untagged 24,Trk1 ip address 10.180.3.1 255.255.255.0 no untagged 5-23 exit vlan 801 name "Storage" untagged 5-23 tagged Trk1 jumbo exit no fault-finder broadcast-storm stack commander "sanstack" spanning-tree spanning-tree Trk1 priority 4 spanning-tree force-version RSTP-operation […]
为什么iSCSI应该隔离SANstream量？ 我试图向我的networking人员解释为什么我们应该隔离stream量。
我正在为数据中心的几个VMware vSphere 5.5和6.0集群扩展存储后端。 我主要在我的VMware体验（Solaris ZFS，Isilon，VNX，Linux ZFS）中使用NFS数据存储，并且可能会在环境中引入Nimble iSCSIarrays ，以及可能的Tegile（ZFS）混合arrays 。 目前的存储解决scheme是基于Nexenta ZFS和Linux ZFS的arrays，它们为vSphere主机提供NFS挂载。 networking连接通过存储磁头上的2个10GbE LACP中继和每个ESXi主机上的2个10GbE交付。 交换机是configuration为MLAG对等方的双Arista 7050S-52机架顶部单元。 在vSphere方面，我使用configuration有2个10GbE上行链路上的LACP绑定的vSphere Distributed Switch（vDS）和networkingI / O控制（NIOC）为VM端口组，NFS，vMotion和pipe理stream量分配共享。 这种解决scheme和devise方法多年来一直运行良好，但添加iSCSI块存储对我来说是一个重大转变。 在可预见的未来，我仍然需要保留NFS基础架构。 我想了解如何在不改变物理devise的情况下将iSCSI集成到此环境中。 ToR交换机上的MLAG对我来说非常重要。 对于基于NFS的存储，LACP是提供path冗余的公认手段。 对于iSCSI来说，LACP通常是不被接受的，MPIO多pathdevise是推荐的方法。 我正在使用万兆以太网，并希望保持简单的双端口链接到每个服务器。 这是为了布线和devise简单。 鉴于上述情况，我怎样才能充分利用iSCSI解决scheme？ 通过LACPconfigurationiSCSI？ 在vDS上创buildVMkernel iSCSI适配器，并尝试将它们绑定到单独的上行链路以实现某种突变MPIO？ 添加更多的networking适配器？
我们有一个新的Synology RS3412RPxs，可以为三个Windows 2008 R2盒子和NFS提供iSCSI目标到一个OpenBSD 5.0盒子。 使用sshlogin到RS3412，使用dd和各种数据块读取和写入小文件和6GB文件，都可以获得出色的磁盘I / O性能。 在iSCSI / NFS客户端上使用dd或iometer，我们可以达到20Mbps（这不是一个错误的20 Mbps）。 我们有点希望能够更好地使用Synology中的多个Gbit网卡。 我已经validation交换机和网卡端口configuration设置为千兆，而不是自动协商。 我们尝试了使用和没有Jumboframe没有区别。 我已经用pingvalidation了MTU目前是9000.已经部署了两个固件升级。 我将尝试iSCSI目标和启动器之间的直接链接以排除交换机问题，但是我的其他选项是什么？ 如果我打破wireshark / tcpdump，我该找什么？
做我的第一台服务器到iSCSI目标，我想我会在服务器（传统的802.3ad团队）上组合我的网卡。 但是，从许多在线资源中我看到这不被推荐，并且应该使用MPIO（在这个build议中没有具体的大小，似乎是从3节点集群到几十个节点以上的大集群）。 我知道MPIO更好，因为它通过独立路由汇聚传输（而传统的NICnetworking团队将是同一个交换机），除此之外，Microsoft还有其他任何原因（数据损坏风险），并且培训材料状态使用MPIO而不是分组？
我有一个OpenSolaris框共享两个ZFS文件系统。 一个是与运行VMware服务器的CentOS盒的NFS连接（磁盘映像存储在ZFS中）。 另一个是通过ZFS上的NTFS格式化与Windows 2008服务器的iSCSI连接。 这两个连接直接通过gig-E（无开关）。 我正在运行munin来监视这些框，但是我不确定我应该期待什么样的数字。 任何人都可以给我一些基准数字来比较或提出build议，从哪里开始调整？ 下面是我看到的NFS统计信息，一旦我在solaris上修复了munin，我就会发布iSCSI：P
当我这样做 localhost:~# iscsiadm -m discovery -t st -p 192.168.0.4 192.168.0.4:3260,1 iqn.2004-04.com.qnap:ts-509:iscsi.linux02.ba4731 192.168.0.4:3260,1 iqn.2004-04.com.qnap:ts-509:iscsi.linux01.ba4731 192.168.0.4:3260,1 iqn.2004-04.com.qnap:ts-509:iscsi.linux03.ba4731 localhost:~# 我看到了可用的目标，但是如何查看我的CentOS5服务器上实际连接了哪些或哪些目标？ 编辑： 当然可以做到这一点，但不能像iscsiadm这样的程序告诉我呢？ localhost:~# ls /dev/disk/by-path/ ip-192.168.0.4:3260-iscsi-iqn.2004-04.com.qnap:ts-509:iscsi.linux02.ba4731-lun-0@ pci-0000:00:1f.2-scsi-0:0:0:0-part2@ pci-0000:00:1f.1-ide-0:0@ pci-0000:00:1f.2-scsi-0:0:0:0-part3@ pci-0000:00:1f.2-scsi-0:0:0:0@ pci-0000:00:1f.2-scsi-1:0:0:0@ pci-0000:00:1f.2-scsi-0:0:0:0-part1@ pci-0000:00:1f.2-scsi-1:0:0:0-part1@
我有一个通过iSCSI公开的HP LeftHand存储的ESXi盒子。 我有一个1TB磁盘的虚拟机，其中800GB被消耗。 磁盘在LeftHand存储上configuration较厚。 在虚拟机上打开了一个快照（这样Veeam Backup and Recovery就可以完成），并且开放了大约6个小时。 在此期间创build了大约5GB的增量磁盘。 快照删除现在已经花费了5个多小时，而且还没有完成。 存储arrays几乎不报告该arrays上的IOPS（大约600，这是背景噪声），没有吞吐量（大约8MB /秒，这又是背景噪声），平均队列深度为9。 换句话说，快照合并过程似乎不是IO绑定，我看不到任何导致快照删除的速度太慢。 它正在工作，通过观看增量文件来判断。 还有什么我应该看看，为什么这个（相对较小）的快照是如此之慢被删除？ 根据VMWare文档 ，我正在观看ls -lh | grep -E "delta|flat|sesparse" ls -lh | grep -E "delta|flat|sesparse"现在，我看到两个增量文件正在改变： -rw——- 1 root root 194.0M Jun 15 01:28 EXAMPLE-000001-delta.vmdk -rw——- 1 root root 274.0M Jun 15 01:27 EXAMPLE-000002-delta.vmdk 我推断一个快照文件正在合并，而另一个正在合并过程中收集三angular洲。 然后新的合并，在这个过程中创build另一个三angular洲。 随着每次迭代（以及大多数迭代），文件大小都在下降，所以我认为最终这个整合过程将会完成（也许我需要从虚拟机离开networking30分钟，让这个完成而不产生任何变化） 。 每百兆大约需要2分钟才能整合。 这从来没有发生过。 正常的Veeam备份下的快照移除需要大约40分钟（所以肯定不会很快，但不会太慢）。 6小时零2分钟后，快照终于被删除。 不过，我仍然想知道是否有任何方法可以排除这类问题（存储性能之外）。