FOG DEPLOYMENT - STORAGE NODE PREP



  • Hi All

    I wanted to post and get some assistance/feedback from the FOG community regarding deploying FOG to a larger environment.

    Environment:
    4500 Endpoints
    400+ Remote Sites (each with a storage node)

    I know there are some large sites by endpoint count out there, however not with 406 remote sites that each have a storage node.
    https://wiki.fogproject.org/wiki/index.php?title=Testimonials (See: Madison Metropolitan School District)

    What is the best way to configure 400+ storage nodes ? I was thinking of using FOG to create an image of a storage node, image the nodes and then reconfigure each with the correct site IP. This unfortunately seems time consuming and in-efficient. Any advice or tricks are welcomed.



  • Hi George

    Yes, the idea is to ultimately schedule imaging from HQ in an-attendant fashion with 1 image for all. (I have assigned a team member to build and test a hardware independent image, I should have the results closer to the end of the week)

    You mentioned a few limitations that I did not realize existed, however still not major stumble blocks.
    For now I suppose we need to prove that we can PXE boot in a production site. (My experience with FOG, albeit somewhat limited, leads me to believe this will work)

    • Prepare replacement machines that are ready to be used in event of failure
    • Prepare and Install standalone FOG Server on site (Pre-Staged with Images)
      *Change PXE Settings (DHCP)
    • Enable PXE boot on target machines

    Progress from this point onward…


  • Moderator

    @steveo There were a few more questions, I’l start with those

    1. Do you need unattended image deployment, or do you require an IT tech to sit in front of the system for image deployment.
    2. How do you invision deploying images? (i.e. someone sitting at HQ deploying images globally, or the site IT techs managing the process?)
    3. In regards to imaging target computers. Is you plan to have one image for all, or one image per model?

    OK, now hold on we are heading into the details.

    First let me say I’m a big supporter of FOG. We have it deployed in our organization and it works very well. BUT (IMO) FOG (in its current state) is geared more towards the SMB market than the enterprise (where I would class you based on the size if your projected deployment). Will fog work for you? Yes, as long as you understand the caveats.

    Your 128KB links are a concern for me for few reasons.

    The first observation is the storage node’s dependency on the database running on the master node. Storage nodes must have 100% access to the database on the master node, or the storage node will not function. We have not tested if there will be any impact on imaging due to communication latency between the Master Node and the Storage Nodes.

    In you install the FOG client on the target computers (not mandatory for imaging with FOG). The FOG client checks in with the master node on a set interval, that interval is 5 minutes by default. With a large campus you might want to increase this check in time to 15 minutes to spread the load out a little. This check-in consumes CPU on the master FOG server as well as network bandwidth. With FOG’s distributed imaging (master node, storage node) all files needed for imaging will be delivered locally, but the FOG clients still communicate over the WAN back to the master node.

    Multicasting only functions from the Master Node. If you need multicast imaging then storage nodes won’t work for you.

    Officially you can only capture images on the Master Node, storage nodes are not intended to capture images. With that said, there is a certain configuration you can use to capture images locally.

    FOG’s replication is one way Master Node to Storage Nodes. Images captured at the Storage Node level (with the specific configuration) will not be replicated back to the master node.

    FOG currently doesn’t have the ability to create storage nodes in an unattended manner. Plus to install FOG, the master nodes and storage nodes need to have internet access.

    I have to hop off and do some other things, I’m not done here. There IS a path forward with FOG. I just want to document the difficulties first then we can work towards a solution.



  • Wow, Thank you for your time George. I do Appreciate it. :)

    Will you deploy software with FOG or some other technology?
    We currently use other deployment tools and will continue to do so. I wont mention the details of the tools, but it would be nice to use FOG snap-ins to maintain the baseline images. This is in part to ensure minimal critical vulnerabilities exist within the environment after imaging and will minimize image updates that will need to sync across the WAN. The next question’s answer will explain the reason for this.

    What is the smallest network link (in bandwidth for a remote site)?
    3 sites on Diginet - 128kbps
    A few (20 or so) on 2 Mbps.
    The average is 4 Mbps and the biggest is around the 10 Mbps range.
    I realize this is not ideal bandwidth, and I am hoping this can work if we limit image updates to at most twice a year. Even that means trickling an image for 2 weeks or more is needed. (possible with FOG?) The 3 slow sites are almost impossible I would imagine, we regularly send a tech with replacement computers. Ill gladly rather send an updated replacement Storage node to image the current machines.

    Do you need to multicast images at the remote sites?
    Multicasting would not be a requirement. I am not seeing the advantage as I am confident that we have 12 hour windows to complete a site.

    I don’t mind the questions, ask away, I do understand the need for these questions.


  • Moderator

    @steveo Sorry I thought about a few more questions on the commute into the office.

    1. Will you deploy software with FOG or some other technology?
    2. What is the smallest network link (in bandwidth for a remote site)?
    3. Do you need to multicast images at the remote sites?

    Stick with me, because they are specific leading questions…



  • Do you plan on using the fog client on your target systems? - YES
    Do the remote sites have 100% full time access to your HQ? - YES
    What hardware will you use at each location for your storage node? - HP 6000 UNITS. Old stock lying around, We had to cut budget and new HP Microservers were not possible without cutting into another project or two. (We realize and accept the risk of the older hardware)
    Do you need 100% coverage for unattended deployment? (i.e. can you function without boot through iPXE) - Need 100% coverage. Currently not using PXE for systems to function.
    Out of the 4500 systems, how many different models do you have? Currently 9 Different Models, all HP - 6000,6200,6300,8000,8200,8300,600 G1 SFF Units 600 G2 and G3. (FOG is going to be crucial towards replacing this ageing fleet)
    Will your images only be created at your HQ and deployed everywhere? YES (WAN Consideration here)
    Will you need to capture images at the remote locations? NO (The odd possibility would be a nice to have)


  • Moderator

    I do want to think about this for a bit. But lets collect a bit more information.

    1. Do you plan on using the fog client on your target systems?
    2. Do the remote sites have 100% full time access to your HQ?
    3. What hardware will you use at each location for your storage node?
    4. Do you need 100% coverage for unattended deployment? (i.e. can you funciton without boot through iPXE)
    5. Out of the 4500 systems, how many different models do you have?
    6. Will your images only be created at your HQ and deployed everywhere?
    7. Will you need to capture images at the remote locations?

    There are more questions, but lets start with those.


 

474
Online

41.3k
Users

11.6k
Topics

110.9k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.