QuicksearchEvents13.10 - 15.10 - Horizons EMEA
![]() Trusted AdBlower Door Test
Luftdichtigkeitsmessung für Gebäude Raum Hamburg ab 160 excl. MwSt www.m-tectum.de Kategorien
|
< XEN-Windowsvirtualisierung mit ZFS-snapshotbasierter Instanzprovisionierung ;) | What have we learned from history? >
SAN is deadWednesday, March 7. 2007Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Very interesting theory!
I agree in most of the points. Some years ago (at the beginning of the SAN) the idea was a "dedicated" network for the storage. In the future, the network is no longer a bottleneck- so why not use the LAN for the storage? But I think this is a long process - the whole SAN-stuff is at the top of itīs developement and of itīs spread.
At the end, there is one fact, that can slow down this development: In the most SANs and LANs are administrated by different departments. The organisational change will be tricky.
Well... maybe..
Some points where I at least partially disagree (my numbers, not references to yours): 1. Some terminology nitpicking... In my book, a SAN is a concept that can be implemented using iSCSI, or FC, or both, or something else. So, I guess, what you mostly mean is: FC is dead. The physical separation of storage and regular traffic is a separate issue, I think. 2. As soon as you start running your SAN traffic over the regular LAN, maybe you have better security mechanisms in place. However: when you do that, you really need these mechanisms. If you just use FC to hook a few servers to some local storage units, you don't really need security beyond what the FC switches provide. If you use your LAN... well, then you're in trouble. There's a reason why you separate your console and iLOM/ALOM traffic from your regular LAN, right? 3. In my mind, iSCSI and FC are conceptually almost the same, except for the variation in physical media. Seen from that conceptual viewpoint, replacing FC by iSCSI makes sense, since overall less specific hardware and software needs to be maintained. 4. If you really need to bring lots of I/O to a massively multi-core system: build an X4500 with a Niagara-II board and put some key application logic on that system (like a database server for instance). Do you really want to throw all the raw data around? Maybe for video streaming and maybe for massively parallel processing of huge amounts of raw scientific data. My take on this: Maybe we shall see iSCSI replacing FC step by step. First for routed traffic, later perhaps local storage traffic. But do we really want to mix regular and storage traffic? I don't think so. Expect perhaps where you want to get rid of local disks in client PCs. But that's a place where FC can't realistically go, anyway.
I strongly believe that SAN and LAN will converge into a single connection into the server. With the availability of massive amounts of bandwidth itīs no problem to mix regular and storage traffic. So "SAN is dead" is a bold, but not incorrect statement. Having a single connection would ease the cabling, would ease the administration and would ease the handling of systems.
Of course you need the stronger security when you use IP. But think the way we trust SANs is equally false like trusting rotating rust as an persistent way to store data without further protection mechanisms. Perhaps it isnīt such an issue for the company with five or so servers, but most of this companies use direct attached storage anyway. We are in need of more secure storage attach. E.g: WWN zones or port based zones are technolgies we used in Ethernet years ago and dismissed them as insecure. At the end, iSCSI has a nice advantage: I donīt have to throw money to companies that sell me extremly expensive gigabit-switches
"I donīt have to throw money to companies that sell me extremly expensive gigabit-switches"
Well... instead you are going to throw money to companies that sell you extremely expensive managed 10GBit Switches with Security and Traffic shaping as well as some extremely expensive uplink bandwidth of... what? Also, let's see the cost of the 10GB infrastructure beyound the edge switches. 10GB edge switches call for an uplink capacity well in excess of that, and very quickly you are talking about some very real money. "We are in need of more secure storage attach." OK, sure, the established FC mechanisms are not that great. On the other hand, for many uses, they don't have to be, they just are not nearly as exposed as regular LAN traffic is. My personal no. 1 learning regarding security is: even if all the technology is perfectly secure and everything is great: you can't do anything against human failures. And since you have to cope with these: nothing beats physical separation... Let's see how this works out in reality. |
The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking open.bc My photos SyndicationComments about Fangorn found a new home Thu, 28.08.2008 11:42 I called it fangorn (sindarin for Treebeard) because itīs th e oldest active machine in my home office. about Fangorn found a new home Thu, 28.08.2008 09:08 Writing this comment on a Sun Ultra6 with 2x450MHz und 2 GB RAM. It is a fine hardware. about MAID, ZFS and some further thoughts ... Thu, 28.08.2008 01:06 There is another aspect of MAI D, when it is done properly, w hich is the design of a physic al enclosure for the dis [...] about MAID, ZFS and some further thoughts ... Wed, 27.08.2008 22:36 I'm not particularly convinced by MAID either. The little I' ve looked at it, they try to k eep the discs alive by d [...] Getaggte ArtikelAMD Apple avs Bahn Blogging Blogosphere braindump Business Travel CeBIT cec cec2006 CMT del.icio.us deutsch dtrace fliegen Fundsache General Hamburg IBM i hate sundays Intel iscsi jumpstart Links Linux lksf Mindfuck Movies Music Musik Niagara Opensolaris Opteron Photographie policy of ... Politik Security Solaris storage Sun suncec2007 sunw t1 The IT Business Ultrasparc ultrasparc t1 Wirtschaft Work ZFS
Blog Administration |