Some weeks ago, we have run into capacity issues in a server farm that provides services to a Computational Grid. This farm run Windows applications and, due to historical reasons, those applications were hosted on the system drive. That configuration have worked for some time, but, finally, we faced the need to move the whole solution to a different local drive. The question, then, was plan simple: how can we accomplish this task without affecting both the application behavior and the production service?
The answer to this question is also simple: NMTools + PLEX modules. The basic idea was already noted in an article I wrote a year ago: “Possible uses for PLEX modules”. Many improvements have been done since then, but the core concepts still apply.
The strategy, then, is to set up a hard-link from the original location to the new one. To achieve this, we will use the capabilities of the PLEX_RunWinCmd module that lives on the remoting library.
The Solution
If your target systems are Windows 2008 or higher you can use a local tool to place the hard-link: mklink. But, If they are Windows 2003, we will need a tool to do it. In our case, linkd.exe from the Windows 2003 Resource Kit. Fortunately, this program can be safely run from a network share, but, to do it successfully, we also need to be sure that we can reach that shared folder from the systems we are trying to change:
"dir \\OurRepositoryServer\OurRepository\linkd.exe" | .\nmagent.ps1 run -profile remoting -file TargetNodes.txt -save
Said that, we can start with the configuration process:
1. Create the target location for your applications:
"md D:\OurTargetDir" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS" -save
The usage of the -session last -filter ";;;SUCCESS" -save as parameters will assure us that we are running each step against the nodes that completed the previous one successfully. You will also have a track record of what really happened so you can focus on the problems in subsequent iterations.
2. Copy the source files to the new location. I did try to use the move command, but it turned out to raise more problems that benefits. Therefore, here is a solution using the xcopy command:
"xcopy C:\OurSourceDir\* D:\OurTargetDir /s /i /y" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS%" -save
If your application is stored under a folder with white spaces in its name, using the old 8.3 notation will work for you. Be aware that this option can be disabled through Group Policies, so review and test this detail beforehand.
"xcopy C:\Progra~1\OurSourceDir\* D:\OurTargetDir /s /i /y" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS%" -save
3. Remove the original files from your source directory. Here we have two options, the rd command can do the job. Unfortunately, it will remove the target folder itself. If custom security ACLs have been placed on that folder we will lose that configuration. I tend to consider easier not dealing with ACLs so, here you have a solution where you first remove the whole files and, afterwards, get rid of the remaining subfolders.
"del /q /f /s C:\OurSourceDir\*.*" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS%" -save
"for /d %i in (C:\OurSourceDir\*.*) do @rd /q /s %~si" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS%" -save
4. Create the hard link between source and destination:
For our Windows 2003 systems…
"\\OurRepositoryServer\OurRepository\linkd.exe C:\OurSourceDir D:\OurTargetDir" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS%" -save
… and for our servers in Windows 2008 (or higher):
"mklink.exe /d C:\OurSourceDir D:\OurTargetDir" | .\nmagent.ps1 run -profile remoting -session last -filter ";;;SUCCESS%" -save
Final considerations
This example is focused on the distributed hard-linking problem. So, I didn't comment anything about how to start, stop, re-schedule my application workloads. This is specific to my scenario, and you will have to take care of yours. In any case, it's something that should be part of any plan.
Just in case this task become something that you do more than once, because, for example, become part of your deployment requirements, it may be interesting to consider a full implementation as individual FX modules. Anyway, any solution it's ok, as long as it works and deliver the intended value.
