Huawei HCIP-Storage common mistakes
Huawei HCIP-Storage · Understand the traps and how to avoid them.
Explaining RAID 2.0+ using legacy RAID-group logic: describing LUNs as being carved from a dedicated set of disks, expecting per-group hot spares, or claiming RAID-TP survives only one or two disk failures.
Most candidates learned RAID 5/6/10 on entry-level arrays and carry that mental model forward. OceanStor V3/V5/V6 instead virtualize disks into chunks, build coalesced key groups (CKGs) inside a disk domain, apply RAID (including RAID-TP) within each CKG, and carve extents from those CKGs to form storage pools and LUNs, so hot spare capacity sits at disk-domain level rather than per RAID group.
What to do instead
Redraw the hierarchy from memory until it is automatic: disk domain → chunks → CKG → RAID level applied inside CKG → extents → storage pool → LUN. Then state explicitly that RAID-TP tolerates three simultaneous disk failures within a CKG and that rebuild uses the spare space distributed across the disk domain, not a single dedicated spare disk.
Treating thin LUNs as physically pre-allocated capacity and being unable to say what actually happens when the storage pool that backs them is exhausted.
SmartThin LUNs consume only metadata at creation and allocate physical extents on first write, so a pool can be heavily over-subscribed. Candidates who assume eager allocation miss capacity planning entirely, and then cannot answer questions about pool subscription rate alarms, write failures, or the protective read-only state the array may enter when free capacity runs out.
What to do instead
Learn three numbers per pool: total capacity, allocated capacity, and subscription rate (allocated versus usable). Be able to state that write I/O fails or is blocked once the pool has no free extents, that capacity alarms fire before the hard limit, and that the operational fix is to expand the pool, migrate LUNs with SmartMigration, or reclaim space by deleting snapshots and enabling SmartDedupe/SmartCompression where licensed.
Configuring only half of the LUN presentation path: either zoning the fabric without creating a mapping view, or creating host/host group/LUN group objects without matching switch zoning, then declaring the LUN broken.
Block access on OceanStor requires two independent steps performed in two places - a zone on each FC switch (ideally single-initiator, single-target) and a mapping view on the array (host or host group with the initiator WWN, LUN group, and mapping view binding them). Candidates often practise on one step only, so in the exam they cannot sequence the end-to-end chain or explain which layer to check when a host sees no disk.
What to do instead
Memorize the ordered chain: HBA WWN → switch zone → array front-end port → host/host group → LUN group → mapping view → host rescan → multipath software. When troubleshooting, verify each link in that order using switch CLI zoning output, DeviceManager mapping view status, and host-side device enumeration before touching the array.
Assuming that installing the OS is enough for redundancy: not checking whether the host actually has multiple paths, or misconfiguring iSCSI/NVMe-oF parameters such as port IPs, CHAP, MTU, VLAN, or initiator IQN/NQN.
A host can see a LUN through a single path while the array still shows two healthy controllers, so a link or controller failure takes the application down. On IP-attached hosts, jumbo frames must match end to end, CHAP secrets must match on both sides, and each initiator must reach every target portal it is zoned or routed to; these are configuration items candidates tend to read about but rarely verify step by step.
What to do instead
Always confirm the multipathing layer explicitly (Huawei UltraPath on supported OSes, or native MPIO/DM-Multipath) and count the paths per LUN. For IP SAN, list the checkpoints as a sequence: initiator IP and subnet, target portal IP, VLAN and MTU consistency, CHAP bidirectional settings, and IQN uniqueness. Practise stating what a host shows when only one path is up versus when all paths are down.
Using snapshot, clone, LUN copy, and remote replication interchangeably, for example claiming HyperSnap protects data if the production array is destroyed, or calling HyperClone a space-efficient point-in-time copy.
The names and the underlying mechanisms are similar enough that candidates memorize a one-line definition and stop. In reality HyperSnap produces a point-in-time image on the same array, HyperClone produces an independent full physical copy, HyperCopy copies LUN data, HyperReplication ships changes to a remote array synchronously or asynchronously, and HyperMetro provides active-active access. Each has a different failure scope and different space and bandwidth cost.
What to do instead
Build a comparison table with four columns per feature: where the copy lives, whether it is space-efficient, what failures it survives, and what it is used for. Anchor the key sentence in memory: a snapshot on the production array does not survive loss of that array, so it complements but never replaces replication or backup.
Quoting RPO and RTO figures without tying them to the replication mode, link distance, and arbitration design - for example promising zero data loss with asynchronous HyperReplication, or describing HyperMetro without mentioning the quorum or arbitration component.
Synchronous replication and HyperMetro depend on round-trip latency, so usable distance is limited and RPO is zero only while the link is healthy; asynchronous replication by definition loses the data not yet transferred. HyperMetro additionally needs a third-site quorum server or equivalent arbitration so that, when the inter-site link fails, one site is fenced and does not accept writes, preventing split-brain. Candidates who skip the arbitration element cannot explain failover behaviour.
What to do instead
For each solution write three lines: RPO/RTO, distance and latency constraints, and behaviour on link failure. Specifically state that HyperMetro requires a quorum component to arbitrate split-brain and that on link loss one site's storage becomes read-only, and that 3DC designs combine HyperMetro for the near sites with asynchronous HyperReplication to the far site.
Treating array snapshots or a single copy on the same array as a complete backup strategy, and never discussing restore verification, backup windows, or dedicated backup storage.
Snapshots are fast and cheap, so they look like backups, but they share the failure domain, capacity pool, and administrative credentials of production. Real backup requires an independent copy (the 3-2-1 principle), a schedule that fits the backup window, and a tested restore. Huawei's answer in this space is backup storage such as the OceanProtect family together with backup software, plus snapshot and replication for operational recovery.
What to do instead
Structure every backup answer as: what is protected, where the copy resides, how often, how long it is retained, and how restore is tested. Explicitly separate operational recovery (snapshots, clones) from disaster recovery (replication, HyperMetro) from backup and archival (OceanProtect, tape or offsite), and mention instant recovery and dedupe/compression as backup-storage capabilities rather than as substitutes for copies.
Describing OceanStor Pacific or the object service only at the level of 'it supports S3', without being able to explain protocol choices, access key authentication, or the difference between erasure coding and replication overhead.
Unified scale-out platforms expose file (NFS/CIFS), object (S3/Swift-compatible), and big-data (HDFS) access over the same pool, and candidates blur these into one protocol. Object access needs an access key ID and secret key, bucket policy or ACL decisions, and optional versioning, WORM retention, and lifecycle rules. Redundancy is also different: EC with N data and M parity chunks has a fixed capacity overhead and tolerates M failures, whereas a replication factor of two or three multiplies raw capacity.
What to do instead
For each access type, state the client protocol, the authentication method, and one typical workload. Then compute the capacity overhead for a given EC scheme and compare it with two-copy and three-copy replication, and list which data services (versioning, WORM, lifecycle, QoS) are configured at bucket level rather than at LUN level.
Answering troubleshooting scenarios by jumping straight to hardware replacement or a controller restart, instead of reading alarms and event logs, confirming severity, and collecting information before changing state.
Exam scenarios usually describe a symptom plus an alarm, and the correct first action is diagnosis: check the active alarm list and event log in DeviceManager, identify severity and probable cause, collect logs with SmartKit device information collection, and only then act. Restarting or replacing parts destroys evidence, can trigger a rebuild or failover, and may turn a single degraded component into an outage.
What to do instead
Adopt a fixed order for every scenario: scope the impact, read alarms and recent events, collect logs, verify redundancy state (replication, multipathing, RAID status), change one thing at a time, and confirm recovery. Know which tool does what - DeviceManager for device-level alarms and configuration, SmartKit for health checks, information collection, and upgrades, eService for remote maintenance and call-home - and be able to name the artefact you would attach to a support case.
Diagnosing slow application I/O as a disk problem without checking the front-end ports, host multipathing, cache behaviour, and back-end bandwidth in a defined order.
OceanStor performance is a chain: host HBA and multipath, front-end port utilization, cache hit ratio and cache partitioning, LUN queue depth, disk-domain back-end load, and rebuild or tiering activity. Candidates latch onto the first plausible cause, usually disks, and cannot explain why latency rose after a path failure, a cache policy change, or a rebuild started.
What to do instead
Learn a metric-to-cause map: high front-end port utilization points to bandwidth saturation, low cache hit ratio or a recent write-policy change points to cache, high disk-domain utilization with long response times points to back-end contention or rebuild, and a single-path host shows doubled latency and no failover. Practise reading these values in DeviceManager performance monitoring and know where SmartQoS or SmartTier would be used to rebalance load.