Single service comparison

Both services expose shared NFS file systems, but their tier and protocol models differ. Filestore is NFS-only (NFSv3, and NFSv4.1 on Premium) and is consumed as fixed provisioning tiers tied to GB. Huawei SFS spans two product variants that are not interchangeable: General Purpose File System (NFSv3 and SMB 2.0/2.1/3.0, EB-level, throughput scales with capacity) and SFS Turbo (capacity-banded performance tiers of 20/40/125/250/500/1000 MB/s per TiB, lower latency). Matching a Filestore Enterprise or Premium workload maps to SFS Turbo, while Basic/High Scale bulk throughput workloads map closer to General Purpose SFS; treat the SFS sub-products as separate targets, not a single service.

Scaling, HA, and data-plane boundaries differ. Filestore tiers provision discrete capacity/throughput with in-class scaling and regional multi-zone availability for Enterprise/Premium; SFS General Purpose throughput follows ~0.02 MB/s per GB plus base bandwidth, and Turbo throughput is provisioned per TiB band. SFS file systems are reachable across AZs within a region over VPC peering, but cross-region sharing and replication rely on separate services (e.g., CBR backups) rather than Filestore's regional synchronous model. Confirm NFS version support, kclient compatibility, locking semantics, and quotas per chosen SFS variant before cutover.

Operational and integration surfaces differ. Filestore is controlled via the Google Cloud Filestore API, gcloud/Console, IAM, and is natively paired with Compute Engine/GKE; SFS is controlled through Huawei Cloud APIs/console with IAM policies, VPC-based security groups, and integrates with ECS, BMS, CBR, and OBS for tiering. Billing also diverges: Filestore charges per provisioned GB-month by tier, while SFS mixes capacity pricing on Turbo and capacity-plus-bandwidth on General Purpose, plus request and cross-region transfer costs. Recompute TCO against actual throughput-band requirements rather than assuming tier-by-tier parity.

Assess the Filestore instance tier, capacity, achieved throughput, IOPS, NFS protocol version, client OS mix, and mount options. Select the SFS variant accordingly: bulk/large-capacity throughput workloads to General Purpose SFS (NFS or SMB), and latency-sensitive or fixed-performance workloads to the SFS Turbo performance band that most closely matches the source MiB/s-per-TiB ratio. Record durability (Filestore regional vs. SFS 99.99999999% designed durability), availability, snapshot/backup, and encryption requirements as migration acceptance criteria.

For data movement, no documented one-click GCP-to-Huawei tool exists; use a copy-based approach over a transient migration host. Mount both the Fileshare export and the target SFS file system on an ECS or migration VM with sufficient egress, then copy with rsync (preserving ownership, permissions, xattrs) or a parallel tool such as rclone/gnu parallel, validating checksums. Network egress between GCP and Huawei should traverse a VPN/Direct Connect-equivalent path; budget GCP egress and Huawei ingress traffic separately. Where capacity is large, stage via OBS as an intermediate object store and parallel-restore into SFS.

Migrate configuration and application bindings last. Re-point application mount entries to the SFS export path, adjust NFSvers, rsize/wsize, hard/soft, and lockd options to values validated against the SFS variant, and update IAM/security-group rules for the SFS VPC access. Re-test concurrent access from multiple ECS/BMS clients, mixed Linux/Windows SMB clients if applicable, quota behavior, and any backup/restore via CBR. Validate performance under peak load against the chosen Turbo band; if a gap appears, re-tier rather than over-provisioning.

Gaps and cost-model differences to plan for. Filestore's per-tier synchronous regional HA and NFSv4.1 advanced features may not have feature-for-feature equivalents in every SFS variant, so treat parity as a per-feature check, not a blanket assumption. Huawei bills SFS by capacity plus (on General Purpose) throughput and (on Turbo) performance band, with separate request and transfer charges; rebuild TCO with peak throughput, request volume, retention, and cross-region/interconnect traffic. Maintain a rollback copy in Filestore or in OBS until post-cutover validation passes, since there is no native cross-cloud rollback.