7 Replies Latest reply on May 28, 2008 2:08 PM by John van Ommen

    Depot file server recommendations



      We are about to start deployment at a new customer who has a cluster of 2 file servers (Windows) for use as the depot.


      The OM 6.x Architecture Planning document recommends putting App Server and File Server on the same box. Why?


      The document says that it will work with SANs.


      If we did that, could we have the depot pointing to storage on the file server?? Won't we just get problems with mapped drives?



        • 1. Re: Depot file server recommendations

          For BL, The file server is in fact a server with an agent where we put the flat files of the depot, nothing to see with a NetApp of something like this. So when the architecture planning recommends putting App Serv and file serv on the same box, it's more to ovoid issue with the network beetween this two components (I imagine, if someone know an other raison, please, explain).

          All of this to say that our 'file server" don't care of the nature of the storage, it just need to see it as a storage "localy" accessible.

          So in your case, if you mont a share for your depot files from the cluster file server (so mapped on the service name of the cluster file server) on your app serv with an agent, you just need to configure the things as usual (the depot targetting the share comming from the cluster file server).

          I hope I'm clear, send me an email if not.


          • 2. Re: Depot file server recommendations

            The trouble with this is that as far as I understand, we have to have the file server logged in, if it is to be able to see windows shares on a NAS box.


            Is there a way around this?



            • 3. Re: Depot file server recommendations

              I don't know how myself, but I've been assured by multiple people: customers & consultants, that it is possible to "mount" a SAN storage system in windows without actually making it a mapped network drive. In that case, no - you won't have to be logged into the box to use it. We do this all over the place, I'm sure. Someone out there has got to know Windows well-enough to explain how this works.


              But, it does work. All the FS needs is an agent. Fred's right that we recommend it's being on the same box because the appserver sends information from it to an agent. If we have to stream that agent from a tertiary source, that bottlenecks us.

              • 4. Re: Depot file server recommendations
                Bill Robinson

                There's a difference between SAN and NAS right? NAS is something like CIFS/SMB or NFS - where as SAN storage is seen like local disks.


                Mounting a windows share that's available to all users (and available if you're not logged in) does not seem to be a trivial exercise...


                so i think the answer is that if it's SAN storage it's easy, if you only have windows shares to connect to, then maybe not so good.


                of course i think you could use the windows Services For Unix and mount and NFS volume from the NAS box?

                • 5. Re: Depot file server recommendations

                  SAN - Easy for BladeLogic

                  A Storage Area Network provides a separate network for storage traffic, typically Fibre Channel. Other computers access a SAN using low level drivers that connect to the SAN through a dedicated network card to provide a "local disk" that is actually an amount of disk-space allocated on a remote storage controller. SANs are great for failover as different computers can "mount" the same resource but SANs are relatively expensive. EMC is a main vendor in the SAN market. Because the drive appears to be a local disk and is available without having to login, BladeLogic can use the disk as a normal local disk.


                  NAS - Hard for BladeLogic

                  A Network Attached Storage device is an appliance-like device that acts as a regular file-server. Other computers can access a NAS device with standard network file sharing protocols such as SMB or NFS. NAS is great for cost, but is not always as powerful as a SAN. Network Appliance is a main vendor in the NAS market. Because the drive appears to be a remotely mounted disk, proper mounting needs to be performed before BladeLogic can use the disk. For Unix / Linux this can be an NFS share that is auto-mounted, and Windows can require a login or a "null session" mount.

                  • 6. Re: Depot file server recommendations

                    I think Microsoft's iSCSI might be worth looking into. We were able to use the iSCSI initiator to map persistent (whether the user is logged in or not) drives to shares on a NetApp device.



                    • 7. Re: Depot file server recommendations

                      I've personally worked with clients who put BladeLogic on SAN, NAS, local storage, or a mix of both. Here are my thoughts.

                      Option One - local storage

                      IMHO, this is the least attractive option. It's also the most popular. The big disadvantage of local storage is that it's a huge hassle to add storage. Imagine if a production client ground to a halt because the depot filled up? This is the kind of situation you face with local storage. In addition, BladeLogic is an application which scales well with multiple app server. The use of multiple app servers all but demands moving the depot (and your patch directory) onto SAN or NAS. Local storage has a few advantages, such as cost. It's performance is respectable also.

                      Option Two - NAS

                      Combining NFS with a NAS in a UNIX environment addresses many of the weaknesses of local storage, without breaking the bank. In my experience, many clients prefer SAN to NAS, but NAS has overlooked advantages. For example, putting databases on a SAN makes a lot of sense because there are frequent writes from a multitude of clients. Putting BladeLogic on NAS makes sense becase there are frequent reads when a job is deployed against hundreds of targets. Writes are comparatively infrequent. As a previous post mentioned, BladeLogic doesn't care where it's installed, as long as it's transparent. NFS is also a very mature technology, with extensive research into performance and optimization.

                      Option Three - SAN

                      Possibly the best option, particularly when cost isn't a big factor. The use of a modern SAN offers redundancy, business continuity, performance, and manageability. The primary drawback is cost. SAN frames generally cost more than NAS servers, and also require the use of expensive fiber HBAs which can cost as much as a low-end Linux server. The use of multiple HBAs is often recommended for additional redundancy. The use of a SAN is particularly attractive when the server is virtualized into VMs, LPARs, or Zones, as this moderates the total investment per server. In other words, it makes more sense to spend $3000 on two HBAs for a seventy five thousand dollar Sun M5000 then it does for a four thousand dollar HP DL380.

                      Option Four - All of the above

                      Often the best option is to use all of the above.

                      Put the BladeLogic DB on SAN and take advantage of the impressive random i/o performance combined with unrivaled redundancy. If possible, use a clustering technology such as VCS or Oracle RAC for DB redundancy.

                      Put the BladeLogic depot, the data store and your patch payloads onto NAS, which offers the best "bang for the buck" combined with competitive read performance. This is particularly attractive if you're using repeaters or deploying software from a network share. Keep in mind that you can see a potential 100% increase in deployment performance when referencing an NFS or SMB share in BladeLogic 7.4 or greater (pg 378 in the 7.4.2 user's guide.)
                      Local storage can be used for installing the app itself, and for hosting the files for the operating system.

                      Red Hat published a technical article which details redundant configurations of NFS and GFS here.