Compare SAN and NAS proposals by the access the application needs, not by a presumed speed advantage.
A decision matrix tests two hypothetical replacement proposals against file-sharing and host-volume requirements, then separates interface fit from the connection and operating details still to verify.
Data center deep-dive series
Does the application need a file path or a host-attached volume?
Start with what must be delivered to the application. If clients need shared files and directories, check the proposed share path, supported file protocol—such as SMB/CIFS or NFS—and access permissions. If a server operating system needs a raw volume it can attach and configure, check which host receives that block volume. SAN is one way to provide block access; a block volume is not, by itself, a file share for users.
A host attached to a block volume can be configured to provide file sharing, but that is an additional service whose inclusion must be checked. Likewise, the ability to attach multiple servers to a SAN does not establish which server will use a volume, provide a share or consume one. Record those roles separately before comparing proposals.
The Fiber Optic Association — The FOA Reference For Fiber Optics - Fiber Optic Network Design
IBM — What Is Block Storage? | IBM
IBM — What Is File Storage? | IBM
How do two hypothetical replacement proposals compare?
This is a hypothetical comparison, not a description of available products. Proposal A supplies file shares to authorized clients but no host block volume. Proposal B supplies SAN block volumes to hosts but no shared file path.
Shared file path for clients or an application
- Proposal A: file shares only
- Interface fits; verification on hold
- Proposal B: SAN block volumes only
- Exclude as proposed; reconsider if a host-provided file service is added
- Detail still needed
- For A, confirm the path, protocol, client permissions and sharing controls. For B, identify the file-service host and who will configure and operate it.
Raw block volume for a server operating system
- Proposal A: file shares only
- Exclude as proposed; reconsider if block access is added
- Proposal B: SAN block volumes only
- Interface fits; verification on hold
- Detail still needed
- For A, confirm whether block access can be added. For B, identify the receiving host and its attachment path.
If both requirements are mandatory, neither proposal meets the whole request within its assumed scope. Combining approaches or adding a service may change the result, but only if the revised proposal specifies that function, its connection and its operating responsibility. “Exclude as proposed” therefore describes a missing interface in the stated offer, not a verdict against an entire product category.
Can the intended hosts and clients actually reach the service?
Interface fit is not proof of attachment. For Proposal B, identify the host-to-storage route, including the host, fabric and storage components. IBM gives Fibre Channel, iSCSI and InfiniBand as examples of SAN connections; none is a mandatory choice for every SAN or proof that a particular host is compatible.
For Proposal A, trace the clients’ route to the proposed file share. For either route, establish the equipment, required network speed and distance rather than treating a protocol name as a complete connection design.
FOA’s fiber-network design guidance supports working from communication requirements and the connection path toward equipment and cabling choices. It is not a SAN/NAS compatibility standard or evidence of performance at this hypothetical site.
If a proposed route uses optical links, compare the transmission equipment and optical interfaces with the cable path. Check a link-loss budget that accounts for link length, fiber type, wavelength, connectors and splices, along with the post-installation insertion-loss test conditions. Passing a link-loss test would not establish that a file share works or that application performance meets its requirement.
What remains unproved after the interface and path match?
For a file-share proposal, confirm actual access rights and the sharing and locking policies. For a block-volume proposal, confirm the required redundancy configuration. In either case, ask whether the required backup and recovery arrangements are included. Neither the NAS name nor block access alone establishes those protections.
Also compare each proposal with the application’s capacity, latency, throughput or IOPS requirements, as applicable, and ask how the proposed values will be verified. No requirements, proposal values or site measurements are available for these hypothetical offers.
The access descriptions and network-design guidance cannot establish that SAN or NAS has a universal performance advantage, or calculate either proposal’s application performance.
When should the decision change?
Keep three outcomes distinct: exclude an offer that omits a mandatory interface as proposed; reassess it if a specified additional configuration could supply that interface; or hold verification when the interface fits but attachment, performance or protection evidence is missing.
A revised offer becomes meaningfully comparable only when it names the service-providing host, connection path and operating responsibility—not merely a different storage category.
Sources
- The Fiber Optic Association — The FOA Reference For Fiber Optics - Fiber Optic Network Design
- IBM — What Is Block Storage? | IBM
- IBM — What Is File Storage? | IBM
No comments:
Post a Comment