Fibre Channel switches usually connect clients to storage. FC is a protocol that is designed explicitly to transport SCSI commands. In fact, the Fibre Channel protocol is a direct extension of the SCSI protocol. All SCSI commands have a FC equivalent, and FC has a few extra ones that allow for networking. Assuming you have all the physics of your FC network ...
Something everyone carries around with them, a camera phone, can be a massive help. Even if the light is so faint that you can barely make it out, you should be able to tell the difference with a camera phone.
Here's an example of a rx cable (with no light coming from it):
Here's an example of a tx cable (with light coming from it):
It's really blurry ...
FCoE doesn't run over regular Ethernet though, it requires Data Centre Ethernet/Bridging - an evolution of Ethernet that is only current supported on a very limited number of, typically high-end, switches such as Cisco's Nexus range.
THIS is a great, and surprisingly short, book that would pretty much tell you everything you'd need to know about the subject ...
You can use multipath FC connections from your servers to the MSA2040 without the use of a switch.
You would connect your HBAs on thee servers to each of the two controllers on the MSA. The MSA2040 was designed for this, and this is a fully supported cabling and VMware host design.
Orange cable meets the OM2 standard. Aqua meets OM3 or OM4 standards (usually OM3). Yellow is singlemode cable.
The OM standards are backward compatible (for the most part; OM1 was defined to be 62.5/125 size; OM2+ are 50/125; but not all manufacturers followed this, just be sure to get the size that matches your equipment or you'll experience some ...
Mainly you want to make sure your VM's will be OK with no disk IO. Installing the VMware tools will take care of this with 4.x and newer. You also want to set the right settings on your ESX hosts related to timeouts, these are detailed on the netapp site in TR-3749
Really it does not matter which protocol you are using for cluster fail overs since the ...
It's a hard disk with a FC interface.
Nope, you probably can't just arbitrarily replace one of them with a disk with a different interface, and different IO characteristics, especially in a storage array. But ask your vendor to be certain, or consult their documentation!
Yes it's possible (it's RFC2625) , I did this ONCE to get me out of a major problem I was having at a remote site and although it worked well enough to allow me to transfer the driver file that had me locked out of the box in all other ways I can't say I'd recommend it.
Sure it'll be fast and reliable but it was crazy complex to setup and maintain so I'd ...
FC doesn't use LAG to achieve link redundancy or aggregation. It uses MultiPath IO (MPIO) to establish multiple logical communications channels and presents them to the storage subsystem as a single device.
I do not see any reason to do this nowadays.
You have modern ethernet NICs with high bandwidth and throughput.
Also you do not introduce all kind of inflexibilities introduced with FC and IPFC.
Some of them:
You can't aggregate FC HBAs -> combine both 10GbE and get 20GbE. You can have them active/standby or use both active/active and get 5Gbps on each.
If you have a single port on each switch that's logging in as a loop port, you need to address this. The first thing I'd do is try unplugging it and plugging it back in. If it still shows up as a loop port when it relogs back into the fabric, take a look at hard-coding the port to be an F port. I found instructions here.
Be prepared that if there's some ...
You should be able to do that. Good guide here:
I'd still leave all the storage mgmt to hypervisor and deal with VHDX only. With shared VHDX, and major improvements around it in WS2016 you don't need raw access to FC anymore. IMHO.
Another way to do it is to use LIO Target: http://en.wikipedia.org/wiki/LIO_Target
At this point, this is the solution that has been merged into the Linux mainline branch and support has been added to a number of distributions.
Point-to-point is the most self-explanatory, and the usual way of connecting just two devices together so they can communicate.
Loop-mode is a way of building a fibre-channel network without using an FC switch. It's analogous to a token-ring network, in that each device in the network forms part of a ring, or loop. I've never seen it used though - the only ...
Fibre channel is generally done through a switch. That said, direct connect is supported, but usually between targets and initiators. Initiators are server HBAs, targets are disk drives (or tapes). I don't know of any software you could run in windows that would allow a server to present its HBA as a target.
What you're trying to do is definitely supported ...
If you have a choice, I'd recommend an HP MSA2040 SAS unit if you only plan to connect to one server. It's a simpler and more effective connection option. Otherwise, this is probably the wrong product for you.
Please read the HP StorageWorks MSA 2040 QuickSpecs guide here.
If you wish to use fiber channel, you have two options: 8Gb and 16Gb SFPs. The MSA ...
theoretically, if device-mapper-multipath detected the same LUN over an iSCSI link it would add it to the available paths, and then it's up to you to make sure you set the failover and IO directions to the right priorities.
I do however doubt you will see the same presentation of the LUN, because I haven't seen any arrays that allowed exporting LUNs and ...
Can optical fibre communication links be used for a length of 100km as
well as 100000km without having to change sender and receiver
In short, no. Any fiber run of decent length is going to require specialized high-power laser optics on both ends as well as some sort of in-line amplification. These days, EDFAs are typically used on very long-...
But which application-layer protocol do the clients use in the LAN to communicate with the servers? Is the data simply transferred via ethernet as well?
Clients don't care how the storage is presented to the servers. If it's FCP, iSCSI, or whatever on the server, it's just a block device to the server and can be presented to the clients however you want to....
8Gb Fibre Channel
Enabling compression on your ZFS zvols/LUNs.
Who is consuming this data? Are you actually seeing bottlenecks?
And remember, it's not always about throughput. Have you taken time to understand your I/O patterns? The mix of read to write? The nature of the transfers?
Can you give more information about the setup?
At the beginning host knows WWNN and WWPN.
Well, forget WWNN. WWNN, theoretically, should be the same on all ports of all HBAs of a computer, but this is rarely the case. Usually it is the same on one HBA, but I've seen a case of multiport HBA with multiple WWNNs. So it's a bit of a mess.
Upon logging to fabric (FLOGI/PLOGI), host gets to know its P_ID ...
Ok, I guess I need to post an answer. In one word it is: insist.
The problem is not resolved 100% to my liking, as we still have one fabric with 1 (one) CRC error sporadically. The other one is clean. But I can live with that.
In any case we won't continue to use the CWDM units for a very long time, but rather switch to a passive DWDM multiplexer next year ...
So you have a single FC LUN presented to both a physical machine and to a VM and you want to use ext3 - is that right?
If so then you need to learn about the difference between block-level and file-level sharing - and quickly, as you've irretrievably corrupted this LUN already.
You have two machines (whether they're physicals or VMs is irrelevant) that ...
Would this be an acceptable production solution?
No. It would not. You do say that you'd like to "experiment with iSCSI." It is fine for experimentation.
I would be using the server like a ISCSI gateway. But I wouldn't want to use Window's horrendous storage pools\RAID solution I would just want to pass clients straight through to the LUNs I served up to ...
Yes, it's very possible - I even did it once, only once however - it's all documented in RFC 4171 and most if not all HBA manufacturers support it, though obviously not as well as they do 'normal' FC.
By the way I did it with Emulex 1105's on RHEL 5.3x64 and Cisco MDS9509's if that helps.
if all 4 are next to each other, would it then be possible to Fibre
Channel cascade them and have a RAID 6 across the nodes?
No, they're not disk shelves, they're full servers with their own CPUs, memory, DAS disks - it's the software that clusters them into pairs for resilience - so no you can't just FC-connect them all together. Oh and 'multiplex' isn't ...
Can we directly connect the SAN to the server HBA and skip on the
Yes, no problem here.
Will we still be able to use vMotion and High Availability using
direct connections from all servers?
What you'll be losing out on, though, is the ability to leverage multiple fibre paths from your HBAs to your SAN, meaning that if your HBAs fail, ...