On a cluster, is it correct that I can compile on the head node, and run the executable on any node of the cluster without recompiling? Is it because all the nodes (including the head node) are the same in some sense and what sense is it?
Is it the same on a grid?
Is it the same on any distributed system (which include clusters or grids)?
Thanks!
Yes, usually the correct usage pattern for a cluster is to compile on the login node, and run the code on the worker nodes. Since this is the correct usage pattern, most systems are designed such that the login node and the worker nodes are identical (or nearly identical).
Grids are different. A grid is a collection of resources under different administrative domains. Most grids standardize on a single operating system and architecture, out of convenience, but the underlying machines may be completely different. Also, there is no head node of a grid, as there may be many submission nodes.
Typically, an application is compiled for the lowest common denominator OS for a grid, which hopefully will work everywhere. For example, on the OSG, the lowest common denomiator is a redhat 5 compatible OS (which include CentOS 5, SL5...). But, the OSG is slowly transitioning to redhat 6 compatible. Therefore, there are different OS's on clusters, but some applications may work on both. Some applications will need to be restricted to only 1 of the OS's. This is an ongoing problem for grids, since they may not be virtualized like Clouds.
Related
I am working on distributed ledger system on 16 GB machine. I want to know how many nodes I can deploy so that all nodes works fine.
Is it hardware depended?
For testing I suggested assign at least 500M for JVM heap, of course heap is not everything what Java application needs. There is also OS and other application, so probably you should be able to fit between 10 and 16 nodes, maybe a bit more. However, if your application is big, you might need to lower above number.
You didn't mentioned number of cores.
If you plan production please speak with R3.
This comes in reference to another question how does windows azure platform scale for my app? stating only multithreaded applications would benefit from multi-core architecture.
My question is that as ASP.NET/IIS (or any other web application and web server) is basically multi-threaded will it not take the advantage of multi-cores?
Assuming the site is a simple web application with some logic that is executed on page display without explicit multithreading implementation.
I believe it is for the console applications or schedules only that require multithreaded programming implemented for it to take advantage of multi cores, please advice.
IIS by design implementation takes full advantage of all available to the OS CPU cores. However it is really application specific to decide which VM size to choose. I barely see anything larger than Medium being used for a Web Role!
The most common case is to use Small VM for a Web Role and scale out to multiple instances when unnecessary. And I always advise customers to start with a Small VM, do some performance/load testing while closely monitoring the VM to assess the need for a larger one (if any). From resilience point of view, as well as durability, and in many cases even performance, it is much better to rely on 4 Small VMs, rather than 1 Large!
Keep in mind that it is always easier, and cost-wise to scale with a smaller step (1 or 2 CPU Cores at once, meaning Small or Medium VM).
There are many business requirements existing in this world that require multi-thread on web application such as generate data and insert it to DB, export excel via AJAX... With a small VM and a minimum RAM with powerful core, if you don't manage your logic well and take advantage of hardware, your RAM would run out shortly.
Improving Web Development Using Virtualization
https://web.archive.org/web/20090207084158/http://aspnet.4guysfromrolla.com:80/articles/102908-1.aspx
Virtualization is, in essence, creating multiple miniature (virtual) PCs inside of your primary PC. One of the great benefits of this is that it allows you to isolate and test an application or set of applications in an environment that is free of other things to interfere. It used to be that in order to get a new machine with a new development environment on it you had to have another piece of hardware, or you had to rebuild your system to the new environment. With virtualization, you simply install the new environment that you need into one of the virtual machines and you run it as necessary. When you're done you can shut it down.
Virtualization is the ultimate in isolation -- it can allow you to do things on one piece of hardware that are simply not possible without it. For instance, you can install software in a test environment on a member server because it won't run on a domain controller. You simply fire up two virtual machines at the same time -- one being the domain controller and the other being the member server. Both virtual machines can run on the same physical hardware at the same time without either being aware that they are sharing a machine. The result is a quick way to implement testing environments.
Virtualization technology allows for the virtual systems to be frozen in place. In other words, the exact spot in the machine that you are at can be frozen for an indefinite period of time. If you work on one project until it's released and stable and need to come back in a year and start working on it again, you can freeze the system when you stop working on the project and then restart it a year -- or more – later. When the system is restarted it will be like time had not passed. The system will be restored exactly as it was left.
This particular feature is great for developers who support multiple systems including consultants who have different clients with different projects that they will have to support over time. You don't have to worry about recreating an environment to test a bug fix; you simply thaw out your virtual machine and go.
Virtualization programs have a feature described as Undo disks. Undo disks allow you to operate on the system and if you decide that you don't want to save your work you simply don’t' accept the changes in the undo disks. Poof. Like magic everything that you did is undone and it's like it never happened.
So I've seen this question, but I'm looking for some more general advice: How do you spec out a build server? Specifically what steps should I take to decide exactly what processor, HD, RAM, etc. to use for a new build server. What factors should I consider to decide whether to use virtualization?
I'm looking for general steps I need to take to come to the decision of what hardware to buy. Steps that lead me to specific conclusions - think "I will need 4 gigs of ram" instead of "As much RAM as you can afford"
P.S. I'm deliberately not giving specifics because I'm looking for the teach-a-man-to-fish answer, not an answer that will only apply to my situation.
The answer is what requirements will the machine need in order to "build" your code. That is entirely dependent on the code you're talking about.
If its a few thousand lines of code then just pull that old desktop out of the closet. If its a few billion lines of code then speak to the bank manager about giving you a loan for a blade enclosure!
I think the best place to start with a build server though is buy yourself a new developer machine and then rebuild your old one to be your build server.
I would start by collecting some performance metrics on the build on whatever system you currently use to build. I would specifically look at CPU and memory utilization, the amount of data read and written from disk, and the amount of network traffic (if any) generated. On Windows you can use perfmon to get all of this data; on Linux, you can use tools like vmstat, iostat and top. Figure out where the bottlenecks are -- is your build CPU bound? Disk bound? Starved for RAM? The answers to these questions will guide your purchase decision -- if your build hammers the CPU but generates relatively little data, putting in a screaming SCSI-based RAID disk is a waste of money.
You may want to try running your build with varying levels of parallelism as you collect these metrics as well. If you're using gnumake, run your build with -j 2, -j 4 and -j 8. This will help you see if the build is CPU or disk limited.
Also consider the possibility that the right build server for your needs might actually be a cluster of cheap systems rather than a single massive box -- there are lots of distributed build systems out there (gmake/distcc, pvmgmake, ElectricAccelerator, etc) that can help you leverage an array of cheap computers better than you could a single big system.
Things to consider:
How many projects are going to be expected to build simultaneously? Is it acceptable for one project to wait while another finishes?
Are you going to do CI or scheduled builds?
How long do your builds normally take?
What build software are you using?
Most web projects are small enough (build times under 5 minutes) that buying a large server just doesn't make sense.
As an example,
We have about 20 devs actively working on 6 different projects. We are using a single TFS Build server running CI for all of the projects. They are set to build on every check in.
All of our projects build in under 3 minutes.
The build server is a single quad core with 4GB of ram. The primary reason we use it is to performance dev and staging builds for QA. Once a build completes, that application is auto deployed to the appropriate server(s). It is also responsible for running unit and web tests against those projects.
The type of build software you use is very important. TFS can take advantage of each core to parallel build projects within a solution. If your build software can't do that, then you might investigate having multiple build servers depending on your needs.
Our shop supports 16 products that range from a few thousands of lines of code to hundreds of thousands of lines (maybe a million+ at this point). We use 3 HP servers (about 5 years old), dual quad core with 10GB of RAM. The disks are 7200 RPM SCSI drives. All compiled via msbuild on the command line with the parallel compilations enabled.
With that setup, our biggest bottleneck by far is the disk I/O. We will completely wipe our source code and re-checkout on every build, and the delete and checkout times are really slow. The compilation and publishing times are slow as well. The CPU and RAM are not remotely taxed.
I am in the process of refreshing these servers, so I am going the route of workstation class machines, go with 4 instead of 3, and replacing the SCSI drives with the best/fastest SSDs I can afford. If you have a setup similar to this, then disk I/O should be a consideration.
Has anyone had experience with developing a distributed system as a grid?
By grid, I mean, a distributed system where all nodes are identical and there is no central management, database etc.
How can the grid achieve even distribution of: CPU, Memory, Disk, Bandwidth etc.?
Something akin to Plan9 perhaps?
wikipedia entry.
What you're actually talking about is a cluster. There is a lot of software available for load balancing etc, even specific linux distros such as Rocks, which comes complete with MPI/PVM and monitoring tools built in.