Alletra 6000 iSCSI Deployment with MTU and Fabric Errors
Contoso Retail is deploying an HPE Alletra 6000 array for 120 SQL Server databases on four HPE ProLiant DL380 Gen11 hosts. Each host has two 25 GbE NICs; the array has four 25 GbE data ports. Two HPE SN2010M switches form separate iSCSI fabrics. The design uses one /24 subnet for both iSCSI data and array management, jumbo frames set to 9000 on the array and switches, and a single host IP per fabric with two array portals. After go-live, each host peaks at 1.1 Gb/s, SQL Server has 45 ms write latency spikes, and Windows reports iSCSI login timeouts every 10 minutes. One host was rebuilt with MTU 1500 and performs marginally better. The team wants to enable LACP between the two switches to combine bandwidth and add a second host IP on the same subnet.
1. Diagnose the throughput, latency, and login-timeout symptoms. Which design choices are contributing?
Read the worked answer
Several faults combine. First, mixing iSCSI data and array management on one /24 exposes storage traffic to management broadcasts and allows management traffic to compete with storage; separate VLANs and subnets are required. Second, MTU 9000 is configured on the array and switches but not consistently on every host, so large frames are dropped or fragmented; the host rebuilt at 1500 performing better is evidence of an MTU mismatch. Third, the host peak of about 1.1 Gb/s suggests one path or a 1 GbE bottleneck is carrying the workload rather than two 25 GbE paths. Fourth, iSCSI login timeouts every 10 minutes often follow spanning-tree topology changes; host-facing switch ports need edge/portfast configuration so link events do not trigger STP recalculation. The proposed LACP between the two switches is wrong because it merges the two iSCSI fabrics into one L2 domain and defeats A/B separation. Adding a second host IP on the same subnet does not fix path selection and may create ambiguous routing.
2. Provide the corrected iSCSI design and a validation plan before production sign-off.
Read the worked answer
Use two independent fabrics, A and B, with no LACP or inter-switch link between them. Place one host NIC in each fabric, each on its own subnet and VLAN; keep array management on a separate management VLAN. Split the four array data ports across both fabrics. Configure MTU 9000 end to end or standardize on 1500 everywhere; do not mix. Enable edge/portfast on host-facing ports while preserving STP on any uplinks. Use MPIO with Round Robin and confirm multiple active sessions per host. For validation, run a mixed read/write benchmark from each host and confirm aggregate throughput above a single 25 GbE port, not 1.1 Gb/s. Break one fabric and verify SQL Server continues with no login timeouts and no more than a brief path transition. Check switch interface counters for drops, pause frames, and CRC errors. Repeat after a switch reboot and after an array port failure. Only then remove the temporary 1500 MTU host.
3. The team insists on LACP between the two SN2010M switches to combine bandwidth. Explain why this is inappropriate and what to do instead.
Read the worked answer
LACP bundles links into one logical channel; it does not create independent storage fabrics. Connecting the two iSCSI switches with LACP creates a single L2 failure domain and can produce loops, broadcast storms, or unexpected traffic crossing from fabric A to fabric B. It also undermines the design intent of multipathing, where the host owns path selection and each fabric is an independent failure domain. If more bandwidth is needed, use both host NICs active through MPIO, distribute array ports across both fabrics, and verify that each path is actually carrying I/O. If switch-level redundancy inside one fabric is required, use an approved MLAG/M-LAG design within that fabric, not a bundle between fabrics. Keep the fabrics physically separate and manage them through a separate management network. The correct answer to 1.1 Gb/s is path utilization and MTU repair, not LACP.