<html><head>
</head>
<body><div>Hi</div><div><br></div><div>On Mon, 2022-11-14 at 15:00 +0100, Tyler Phillippe via Users wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Good idea! I setup a RAM disk on both of those systems, let them sync, added it to the cluster. <br></div><div dir="auto"><br></div><div dir="auto">One thing I left out (which didn't hit me until yesterday as a possibility) is that I have the iSCSI LUN attached to two Windows servers that are acting as a Scale-Out File Server. When I copied a file over to the new RAMdisk LUN via Scale-Out File Server, I am still getting 10-20MB/s; however, when I create a large file to the underlying, shared DRBD on those CentOS machines, I am getting about 700+MB/s, which I watched via iostat. So, I guess it's the Scale-Out File Server causing the issue. Not sure why Microsoft and the Scale-Out File Server is causing the issue - guess Microsoft really doesn't like non-Microsoft backing disks<br></div><div dir="auto"><br></div></blockquote><div><br></div><div><br></div><div>Not with Microsoft, but with overall iSCSI performance. For the older iSCSI target - IET - I used to use the following settings:</div><div>InitialR2T=No </div><div>ImmediateData=Yes </div><div>MaxRecvDataSegmentLength=65536 </div><div>MaxXmitDataSegmentLength=65536 </div><div>MaxBurstLength=262144 </div><div>FirstBurstLength=131072 </div><div>MaxOutstandingR2T=2 </div><div>Wthreads=128 </div><div>QueuedCommands=32</div><div><br></div><div>Without that iSCSI LUNs were very slow independently of backing device speed.</div><div>Probably LIO provides a way to set them up as well.</div><div><br></div><div>Best,</div><div>Vladislav</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto">Does anyone have any experience with that, perhaps? Thanks!!<br></div><div style="16px"><br></div><div style="16px">Respectfully,<br></div><div style="16px"> Tyler<br></div><div><br></div><div><br></div><div><br></div><div>Nov 14, 2022, 2:30 AM by Ulrich.Windl@rz.uni-regensburg.de:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi!<br></div><div><br></div><div>If you have planty of RAM you could configure an iSCSI disk using a ram disk and try how much I/O you get from there.<br></div><div>Maybe you issue is not-su-much DRBD related. However when my local MD-RAID1 resyncs with about 120MB/s (spinning disks), the system also is hardly usable.<br></div><div><br></div><div>Regards,<br></div><div>Ulrich<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Tyler Phillippe via Users <users@clusterlabs.org> schrieb am 13.11.2022 um<br></div></blockquote></blockquote></blockquote><div>19:26 in Nachricht <NGmE_x7--3-9@tutamail.com>:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hello all,<br></div><div><br></div><div>I have setup a Linux cluster on 2x CentOS 8 Stream machines - it has <br></div><div>resources to manage a dual primary, GFS2 DRBD setup. DRBD and the cluster <br></div><div>have a diskless witness. Everything works fine - I have the dual primary DRBD <br></div><div>working and it is able to present an iSCSI LUN out to my LAN. However, the <br></div><div>DRBD write speed is terrible. The backing DRBD disks (HDD) are RAID10 using <br></div><div>mdadm and they (re)sync at around 150MB/s. DRBD verify has been limited to <br></div><div>100MB/s, but left untethered, it will get to around 140MB/s. If I write data <br></div><div>to the iSCSI LUN, I only get about 10-15MB/s. Here's the DRBD <br></div><div>global_common.conf - these are exactly the same on both machines:<br></div><div><br></div><div>global {<br></div><div> usage-count no;<br></div><div> udev-always-use-vnr;<br></div><div>}<br></div><div><br></div><div>common {<br></div><div> handlers {<br></div><div> }<br></div><div><br></div><div> startup {<br></div><div> wfc-timeout 5;<br></div><div> degr-wfc-timeout 5;<br></div><div> }<br></div><div><br></div><div> options {<br></div><div> auto-promote yes;<br></div><div> quorum 1;<br></div><div> on-no-data-accessible suspend-io;<br></div><div> on-no-quorum suspend-io;<br></div><div> }<br></div><div><br></div><div> disk {<br></div><div> al-extents 4096;<br></div><div> al-updates yes;<br></div><div> no-disk-barrier;<br></div><div> disk-flushes;<br></div><div> on-io-error detach;<br></div><div> c-plan-ahead 0;<br></div><div> resync-rate 100M;<br></div><div> }<br></div><div><br></div><div> net {<br></div><div> protocol C;<br></div><div> allow-two-primaries yes;<br></div><div> cram-hmac-alg "sha256";<br></div><div> csums-alg "sha256";<br></div><div> verify-alg "sha256";<br></div><div> shared-secret "secret123";<br></div><div> max-buffers 36864;<br></div><div> rcvbuf-size 5242880;<br></div><div> sndbuf-size 5242880;<br></div><div> }<br></div><div>}<br></div><div><br></div><div>Respectfully,<br></div><div> Tyler<br></div></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><div>_______________________________________________<br></div><div>Manage your subscription:<br></div><div>https://lists.clusterlabs.org/mailman/listinfo/users<br></div><div><br></div><div>ClusterLabs home: https://www.clusterlabs.org/<br></div></blockquote><div dir="auto"><br></div><div>_______________________________________________<br></div><div>Manage your subscription:<br></div><div><a href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br></div><div><br></div><div>ClusterLabs home: <a href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br></div></blockquote><div><br></div><div><span></span></div></body></html>