Hi @george1421 , they will all be physical HP6000 SFF units running as storage nodes. (I imagine managing and replicating all settings across 400 full fog servers will be an administrative nightmare with overhead that I simply cannot afford, the requirements are such that the limitations of a storage node are not a factor in the use case for this implementation)
Latest posts made by Steveo
-
RE: FOG DEPLOYMENT - STORAGE NODE PREP
-
RE: FOG DEPLOYMENT - STORAGE NODE PREP
Hi @george1421
This has taken a little longer than expected to get to this point. I am happy to report that all our testing indicates this will work. (Minus some sites with slower links). This does however now push me towards the next steps - Mass preparation of storage nodes.
What are your thoughts going forward? -
RE: FOG DEPLOYMENT - STORAGE NODE PREP
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…
-
RE: FOG DEPLOYMENT - STORAGE NODE PREP
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.
-
RE: FOG DEPLOYMENT - STORAGE NODE PREP
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) -
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.
-
RE: 1.5.0-RC-10 - Storage Nodes Displaying Incorrectly - "A valid database connection could not be made"
@wayne-workman , Thank you for clarifying. After some confusion I finally managed to resolve this on my test hosts. I will now replicate the change on my original environment. (My database knowledge is to blame).
Maybe if I ask nicely, we could request that this error be made a little more intuitive within the interface? (The error statement itself caused a slight offset within the interface, which is corrected after fixing the error)
(Again, I blanked out the IP) -
1.5.0-RC-10 - Storage Nodes Displaying Incorrectly - "A valid database connection could not be made"
This issue is encountered on the main screen under storage nodes
When entering the node - all details are offset.
I have blanked out the IP on the above screenshot. This replicated on 2 fresh installations. Am I missing something and this is a legitimate database issue or is this an interface issue?