There really is no "ideal" environment and cost for running MongoDB (or any other database for that matter). There will be very cheap solutions that will give you enough space, but not enough RAM, there will be middle range options where you have enough RAM most of the time but at busier periods you exceed the memory limitations and the disk is too slow to cope with the increased page fault activity.
As always, it will be a trade of between what you can afford and what is best. In terms of general recommendations:
The cores and space will matter less than your available RAM and whether or not you can keep your working data set (active data plus indexes) in RAM - that is the key to performance. You won't really be able to tell until you start with real traffic, but if you have decent testing you should be able to estimate it.
I would recommend using MMS to track the stats, it's free and it includes a memory graph that will track your resident memory usage and many other things.
FYI - there is no global read lock and as of 2.2 (release candidate is up for testing as of writing this), the global write lock has been replaced by a database level lock. Have a look at the relevant concurrency presentations for an in-depth discussion on the 10gen website.
Another thing to make sure of is that you have more than one MongoDB instance, it is highly recommended that you run a replica set (primary, secondary, arbiter minimum) and not a single instance.
Sharding can be used to help scale out horizontally though - that is correct, it allows you to add more resources to your cluster without having to increase the resources available on a particular host. However, it is not really correct to say that MongoDB runs "best" when sharded - sharding has overheads (you need more servers to run the config DB, mongos processes etc.).
MongoDB runs best when your working set can fit in RAM and your disk subsystems are fast enough to keep up with the amount of data you want to write to disk. Whether than requires a single replica set or a sharded environment will very much depend on how you use it.
This is quite an involved question, but I will give a brief answer on each. You should try these out, then ask a more specific question (like give details about RAM availability and utilization, with working data set size to diagnose page faulting for example).
Un-expected shutdown resulting as corrupt collections
You don't list your full version, but make sure you are on a later version of 2.0 at least and preferably 2.2 (2.2.3 is in release candidate status as of writing this). There were multiple Windows related fixes later in the 2.0 branch and several of them dealt with making the Windows build less susceptible to hard crashes (which can lead to corruption).
MongoDB not releasing disk space for deleted objects (currently its around 28-GB and growing)
This has been covered in numerous other posts and discussions - see my answer here:
https://stackoverflow.com/questions/13390160/does-mongodb-reuse-deleted-space
Increased number of Page Faults
No control over data in RAM (unable to pre-load required data in RAM and remove after few minutes)
As mentioned above, page faulting and data fitting into RAM requires more details - how much data do you have, what is your working set size, do your indexes fit into memory etc. There are also numerous discussions on the mongodb-user Google group as well as Stack Overflow on this, and how to track this in MMS - a bit of searching for common approaches here is advised before you submit a new question. You should also note that page fault reporting in Windows can be tough to interpret thanks to the OS reporting "soft" page faults (already in memory but not owned/touched by a process) and "hard" page faults (actually paged from disk) in pretty much the same way.
A note about pre-loading, you can do this with the touch command in 2.2+, for indexes, data or both (see the linked page for options).
Frequent DB Errors like: Unable to read data from the transport connection...
Again, this will require logs, an idea of the relative load on the system etc. More detail definitely required - you could just be hitting a timeout or similar because you are overloading the DB. I would advise a separate question if these errors persist after you resolve other problems
Move MongoDB to Linux (provided that my .Net application using this DB will reside on Windows Server within same LAN)?
More people use MongoDB on Linux than Windows so it is more extensively tested and used by the community on that platform, but there is significant usage on Windows and large installations. Moving OS will not necessarily solve or automatically fix issues. If your data will not fit in RAM on Windows, it will likely not fit on Linux either for example, nor will it change how MongoDB reuses deleted space.
Setup a 2-servers replica set with Master on Windows and Slave on Linux ? OR
You should always run a replica set (minimum primary, slave, arbiter), regardless of the OS. It's just a good idea in general, but particularly if you are seeing some of the issues you describe. While in theory you can mix OS like you mention, I would recommend picking one or the other and just using that.
Best Answer
You shouldn't scan the folder in which mongodb stores it's data files, as this will degrade performance. The location is set by using the
--dbpath C:\Where\You\Want\The\Filesflag at runtime.With regards to best practices for clustering, I'd recommend taking a look at the Infrastructure Requirements for a Sharded Cluster page.
At a minimum, you will need three config servers, two or more shards and one or more MongoSes