I am currently kind of having trouble to understand between NAS and SAN.
As far as I figured out, NAS and SAN are kind of defined as below.
NAS(Network attached storage)
- Usually used as file storage and use Ethernet Infrastructure to communicate
- As file storage, support protocols like NFS, CIFS, SMB, HTTP(S)
SAN(Storage Area Network)
- Network Protocol to communicate with block storage for data access.
- Configured with separated network system
- Commonly based on Fibre Channel(FC) technology.
- Could use iSCSI(in small and medium sized business) or FCoE for less expensive alternative to FC
So, below is my questions.
1. Is File Storage and Block Storage are the solutions? I researched and found that NAS is File Storage Solution and SAN Storage is Block Storage Solution.
- In that case, are their base infrastructure(storage device) same? Only different with protocols, network devices, may be storage os something that controls underline device and way of usage?
2. I found there are NAS Solutions that support iSCSI. But I found that iSCSI is SCSI Protocol that use TCP/IP Network system and SCSI is for block level storage communication protocols.
- And Now I am confused. NAS is a file storage solution and how could that support iSCSI Protocol?
3. Are AWS root disk and EBS storage SAN Storage?
- I read that SAN Storage configuration could be expensive so iSCSI or FCoE are less expensive way to configure.
- With what technology AWS storage Infrastructure is configured??
I am kind of newly studying of these storage part computer science and got some questions.
Is there anyone can explain those questions clearly?
Thank you.
It depends on what you call a "Solution". The basic infrastructure is the same it's a some kind of a "storage server" (storage system) with physical disk(s), but it very much dependent of technologies, vendors and various options. Typically, a storage system provides access to its physical disks with different protocols of 2 main groups: block-level protocols like SCSI or rarely ATA on one hand, or file-level protocols like NFS, CIFS, etc on the other. It doesn't mean, a storage system can't work in both, block and file modes.
Storage network - SAN can be build over FC, FCoE, converged infrastructure, pure TCP/IP for iSCSI, Infiniband or any other infrastructure. Typically, when people say "SAN" they mean Block storage devices and FC protocol, but it doesn't mean, that a file storage - NAS can't be connected with SAN and vice verse.
Related
I have a distributed program which communicates with ZeroMQ that runs on HPC clusters.
ZeroMQ uses TCP sockets, so by default on HPC clusters the communications will use the admin network, so I have introduced an environment variable read by my code to force communication on a particular network interface.
With Infiniband (IB), usually it is ib0. But there are cases where another IB interface is used for the parallel file system, or on Cray systems the interface is ipogif, on some non-HPC systems it can be eth1, eno1, p4p2, em2, enp96s0f0, or whatever...
The problem is that I need to ask the administrator of the cluster the name of the network interface to use, while codes using MPI don't need to because MPI "knows" which network to use.
What is the most portable way to discover the name of the high-performance network interface on a linux HPC cluster? (I don't mind writing a small MPI program for this if there is no simple way)
There is no simple way and I doubt a complete solution exists. For example, Open MPI comes with an extensive set of ranked network communication modules and tries to instantiate all of them, selecting in the end the one that has the highest rank. The idea is that ranks somehow reflect the speed of the underlying network and that if a given network type is not present, its module will fail to instantiate, so faced with a system that has both Ethernet and InfiniBand, it will pick InfiniBand as its module has higher precedence. This is why larger Open MPI jobs start relatively slowly and is definitely not fool proof - in some cases one has to intervene and manually select the right modules, especially if the node has several network interfaces of InfiniBand HCAs and not all of them provide node-to-node connectivity. This is usually configured system-wide by the system administrator or the vendor and is why MPI "just works" (pro tip: in not-so-small number of cases it actually doesn't).
You may copy the approach taken by Open MPI and develop a set of detection modules for your program. For TCP, spawn two or more copies on different nodes, list their active network interfaces and the corresponding IP addresses, match the network addresses and bind on all interfaces on one node, then try to connect to it from the other node(s). Upon successful connection, run something like the TCP version of NetPIPE to measure the network speed and latency and pick the fastest network. Once you've gotten this information from the initial small set of nodes, it is very likely that the same interface is used on all other nodes too, since most HPC systems are as homogeneous as possible when it comes to their nodes' network configuration.
If there is a working MPI implementation installed, you can use it to launch the test program. You may also enable debug logging in the MPI library and parse the output, but this will require that the target system has an MPI implementation supported by your log parser. Also, most MPI libraries use native InfiniBand or whatever high-speed network API there is and will not tell you which is the IP-over-whatever interface, because they won't use it at all (unless configured otherwise by the system administrator).
Q : What is the most portable way to discover the name of the high-performance network interface on a linux HPC cluster?
This seems to be in a gray-zone - trying to solve a multi-faceted problem among site-specific hardware (technical) interface naming and theirs non-technical, weakly administratively maintained, preferred ways of use.
As-is State :
ZeroMQ can (as per RFC 37/ZMTP v3.0+) specify <hardware(interface)>:<port>/<service> details :
zmq_bind (server_socket, "tcp://eth0:6000/system/name-service/test");
And:
zmq_connect (client_socket, "tcp://192.168.55.212:6000/system/name-service/test");
yet has no means, to my knowledge, to reverse-engineer the primary use of such an interface, in the holistic context of the HPC-site and it's hardware configuration.
Seems to me, your idea of pre-testing the administrative mappings via MPI-tool first and letting ZeroMQ deployment use these externally detected (if indeed auto-detectable, as you assumed above) configuration details for a proper (preferred) interface usage.
The Safe Way to Go :
Asking the HPC-infrastructure Support Team ( who is responsible for knowing all of the above and trained to help Scientific Teams to use the HPC in the most productive manner ) would be my preferred way to go.
Disclaimer :
Sorry in case this did not help your will to read & auto-detect all the needed configuration details ( a universal BlackBox-HPC-ecosystem detection and auto-configuration strategy would hardly be a trivial one-liner, I guess, wouldn't it? )
I am new to storage domain .can Some one please help me in understanding the below things
Can a storage sever be connected to Application server?
1.How storage servers are different from applications servers
2.Can multiple application servers connect to storage serves over the network
3.what kind of files will be served by NAS and SAN severs
Firstly this question belongs on server-fault stack exchange still it is a good conceptual question...
So the answers are~~
Yes storage servers can connect to application server (app servers are in fact software frameworks or specific portion of a server program implementation). Application servers communicate with storage server to store / retrieve / process data.
Apart from high disk space, what else is different about storage servers you may ask ? In many cases, they come with a host of specialized services. This can include storage management software, extra hardware for higher resilience, a range of RAID (redundant array of independent disks) configurations and extra network connections to enable more users to be desktops to be connected to it.
Where as, application server is a software program that handles all application operations between users and an organization's backend business applications or databases. An application server is typically used for complex transaction-based applications. To support high-end needs, an application server has to have built-in redundancy, monitor for high-availability, high-performance distributed application services and support for complex database access. For mobile computing, mobile app server is mobile middleware that makes back-end systems accessible to mobile applications to support Mobile application development. Frankly speaking, application servers lie in the territory between database servers and the end user, and they often connect the two.
Multiple application servers CAN and in reality DOES connect to storage serves over the network or even directly. but for concurrent access to data there must be guaranteed reliability of data between transactions. Something like ACID properties.
Cming to the third one, NAS, it turns out, is NOT really storage networking. Actual network-attached storage would be storage attached to a storage-area network (SAN). NAS, on the other hand, is just a specialized server attached to a local-area network. All it does is make its files available to users and applications connected to that NAS box — much the same as a storage server. To further conceptualize the difference between a NAS and a SAN, NAS appears to the client OS (operating system) as a file server (the client can map network drives to shares on that server) whereas a disk available through a SAN still appears to the client OS as a disk, visible in disk and volume management utilities (along with client's local disks), and available to be formatted with a file system and mounted.
I deploy Openstack for private cloud. Faced a problem of a choice of file system for storage. That live migration between physical servers worked.
Configuration:
HP P2000 FC disk massif and four computing notes which are connected on through HBA FiberChanel to one general lun on storage.
Advise clustering file system without use of iscsi, fcoe... etc... Only FC. As VMFS from Vmware...
Thx!
I can tell you about OpenStack Object Storage aka Swift, you can use fibre channel across zones/regions/geo-cluster for data transfer.
Hope it helps.
There are no good cluster filesystem alternatives to VMware VMFS on Linux. You may look at Oracle OCFS2, Red Hat GFS2, SGI CXFS and Symantec VxFS. All of them are dated. Newer generation of filesystems moved to distributed architecture over local drives (as compared to shared SAN) for scalability.
I think you need object file system Ceph, Lustre, NetApp object storage etc.
But you can create san cluster. I dont know MSA maybe not supported but 3Par have HP peer persistence.
Say my data store is going to increase in size, if the data increases how storage manager would manage the data. Does storage manager split the data with different domain machines ( definitely that is not the case)?
How exactly would the process work? What is the recommendation in this area, key-value store?
If you have a storage manager that is soon to run out of disk space, you can startup a new storage manager with a larger disk subsystem or that points to extensible cloud storage such as Amazon S3. Once the new storage manager is up-to-date the old one can be taken offline. This entire operation can be done while the database is running. Generally, we also recommend that you always run with at least 2 storage managers for redundancy.
If you have more questions, feel free to direct them to the NuoDB forum:
http://www.nuodb.com/community
NuoDB supports multiple back-end storage devices, including the Hadoop Distributed File System (HDFS). If you start a broker configured for HDFS, you can use HDFS tools to expand distributed storage on-the-fly and there's no need for any NuoDB admin operations. As Duke described, you can transition from a file-based Storage Manager to an HDFS one without interrupting services.
NuoDB interfaces with the storage layer using filesystem semantics for discrete storage units called "atoms". These map easily into the HDFS directory structure, simplifying administration on that end.
I have a TCP/IP based component which is communicating with a c++ based system. In fact it is reading raw bytes from that system and then marshaling those raw bytes in objects and storing it in the DB. This multi-threaded tcp/ip based component is in java and could be deployed on a dual core or quad core processor (not sure if its important for my question but nevertheless a detail I am giving). Now I have a few questions:
How can I scale this tcp/ip based component. This component is deployed on a server and is listening to a port. In future if there's more data that is envisaged at this point that comes from the C++ system we should be able to scale this java component.
What about security. One thing which I can probably do is employ this communication on secure sockets or probably get encrypted data (any particular encryption that I could use here??). Any other way to take care of security?
There is also a requirement of high availability to be satisfied. How do I handle that? How could I possible have redundancy here?
Yes, we are working on the system architecture of a product and therefore, I was wondering if some experienced architect or designer could help me.
How can I scale this tcp/ip based component. This component is deployed on a server and is listening to a port. In future if there's more data that is envisaged at this point that comes from the C++ system we should be able to scale this java component.
You normally use a network load-balancer to scale these kind of services across multiple servers. That load-balancer can distribute load using a variety of algorithms, such as:
CPU load (usually measured with snmp)
Client ip address (if you need persistence when mapping clients to your services)
Number of active sockets
etc
Look at HAProxy for a popular open-source load-balancer. F5 has the most popular commercial load-balancer solution.
What about security. One thing which I can probably do is employ this communication on secure sockets or probably get encrypted data (any particular encryption that I could use here??). Any other way to take care of security?
As mentioned, SSL is an option, but understand that is a big performance hit on your services if you encrypt on the same hardware that is performing your customer services. One option along these lines is using a commercial load-balancer that implements SSL in hardware; that load-balancer would then forward unencrypted sockets to your TCP services farm.
Under some circumstances you can use IPSec network-level encryption; often, this is another network hardware solution. Typically your clients will download an IPSec application that resides on their PC... then they make a connection into your IPSec server, which encrypts between their client and your IPSec termination point
SSH Tunneling with port-forwarding (low-tech solution)
tcpcrypt looks interesting as a future technology, but I'm not sure how mature it is right now.
There is also a requirement of high availability to be satisfied. How do I handle that? How could I possible have redundancy here?
A lot depends on what you mean by high availability, and what kind of recovery timing you need. At a high level, you have a few options:
DNS-based HA works if you don't need client to socket mapping persistence; if you use DNS, you need to be willing to accept typical DNS A-record timeouts (usually people don't go lower than ~5 minutes / 300 seconds). This also assumes you find a way to synchronize your databases across multiple sites.
Load-balancer solutions. Same issue with synchronizing back-end databases
To do any kind of HA, you probably want to hire a consultant that has a proven track record of implementing these services (if you don't have this kind of resource in-house).