Information Technology Reference
In-Depth Information
But during the upgrade process, the entire network will not be replaced at once; rather,
there will be a series of upgrade and replacement scenarios. This obviously does not lead to
a simple network infrastructure; that is why it would be wise to keep documentation detail-
ing which nodes have been replaced and which have been retained. And even if the nodes
that were not replaced scale very well or use the same hardware as the new infrastructure
(which is to say that you are dealing with a uniform and simple network infrastructure),
these nodes are still older than the rest of the network. Keeping tabs on them might prevent
spending a lot of time looking for failing hardware because the older ones will be the first
ones to be checked for inconsistencies and errors.
Standardizing Configuration and Documentation
For a cloud computing infrastructure, homogeneity cannot be stressed enough. All servers,
network nodes, network-attached storage (NAS), automation devices, and the rest of the
essential hardware must be configured in the same exact way—the same operating system,
software, and firmware. Having different configurations will lead to incompatibilities
and inconsistencies in performance as well as other unforeseen issues. In this way, we can
immediately cross out incompatibility or configuration issues when problems arise.
This can be an issue in older systems when some parts are being upgraded and some are
not because they are still “acceptable,” leading to possible inconsistencies. It is always best
to upgrade everything, even though this somewhat disagrees with the concept of modularity,
where modules can be replaced without affecting the whole, but this is for the sake of con-
figuration standardization. The system will still be operational 100 percent, but what we are
trying to avoid are the “possible” problems that inconsistency fosters. As for the really quick
development of software and hardware, that should not be much of a problem, even though
right after you set up your brand-spanking-new data center with all the latest hardware, it
could be considered second tier after a few months. The fact is that hardware just evolves and
not by leaps and bounds, so your quad-core 3.5 GHz CPU from last year will still perform
very much like the newer 4 GHz CPU that was just released. And with your configuration
optimized for your current setup, there should be no worries about performance differences.
That is the same reason there are still dual-core “business” PCs running Windows XP being
sold today; the configuration is still powerful enough for office tasks.
A document establishing all configurations for various devices and software must be cre-
ated to ensure that there is no second-guessing and miscommunication regarding device and
software configuration so that decisions made by all administrators and technical personnel
are based on the same exact document. The document must be updated regularly because
configurations and settings change according to business needs, and there must always be a
person assigned to the task. The same person should also enforce compliance across the envi-
ronment, making use of model-driven management tools to discover and collect information
about all relevant devices to ensure that they are configured correctly.
Implementing Change Management Best Practices
Change is inevitable; that much is certain. What is not certain are the changes them-
selves. It can be an exciting time for some, a chance for new opportunities and growth,
while for others it can be a time of loss, threat, or disruption. The outcome rests mostly
Search WWH ::




Custom Search