Dispatches¶

What is vCenter Server Watchdog?

If you’ve done any research into the high-availability options available for vCenter Server 6.0, hopefully you have had a chance to read the VMware vCenter Server 6.0 Availability Guide written in collaboration with Technical Marketing and Global Support Services as well as KB 1024051. And you might have noticed particular sections that refer to the vCenter Server Watchdog. But what exactly is the vCenter Server Watchdog?

Enabled “out of the box” in 6.0, the vCenter Server Watchdog provides better availability by periodically verifying the status of vCenter Server.  It does this in two ways:

• The PID Watchdog monitors the processes running on vCenter Server
• The API Watchdog uses the vSphere API to monitor the functionality of vCenter Server.

If any services fail, the Watchdog attempts to restart them. If it cannot restart the service because of a host failure, vSphere HA restarts the virtual machine running the service on a new host.

That’s sounds slick, right? Well, let’s dive in and take a look at each of these watchdogs in detail.

Reconfiguring and Repointing Deployment Models in vCenter Server 6.0 Update 1

In my last blog post, we discussed some of the new features and capabilities found in vCenter Server 6.0 such as how you can quickly and easily update the vCenter Server Appliance 6.0 to Update 1.

Now, it’s time to focus our attention on a two key enhancements found in vCenter Server 6.0 Update 1 - both the appliance and Windows-based form factors:

• Reconfigure – You can now reconfigure an embedded deployment node to an external deployment model, also known as MxN.

• Repoint – Simplified repointing of a management node in an external deployment model from one external Platform Services Controller to another external Platform Services Controller.

Why is this important?

The reconfiguration enhancement enables you to take an existing embedded deployment and transition it to a more optimal external deployment model – MxN.  There is also the simplified ability to repoint a management node to another Platform Services Controller which enables you to quickly recover from an external Platform Services Controller failure and to distribute load to alternate nodes that are in the same SSO domain.

Before moving forward with either the reconfigure or repoint operations, there is a key set of requirements that you need to meet.

Introducing the Platform Services Controller Interface in vCenter Server 6.0 Update 1

Back in March, we introduced vSphere 6.0 and the new architecture for vCenter Server. With this new architecture you learned about the Platform Services Controller, a new functional component of vCenter that moves beyond just Single Sign-On to include additional platform services such as:

• Licensing Service
• Certificate Authority (VMCA)
• Certificate Store (VECS)
• Lookup Service for Component Registrations

In the 6.0 release, administration and configuration of the Platform Service Controller was primarily performed by an SSH session, the vSphere Web Client and selecting the node in System Configuration, or through the Direct Console User Interface of the appliance.

In vCenter Server 6.0 Update 1, we're excited to introduce the next stage of the administration with the Platform Services Controller Interface, a fully HTML5-based interface to administer and configure many of the services that run on the PSC.

Confessions of an Energy Consciousness Mind

I have a confession.

My data center kit has been using too much energy.

Having kit available at my disposable is great, but I have been wasting this resource when it's not required by my workloads. And if there's one thing I try to be conscious of, it's energy consumption. Just ask my kids who I chase from room to room turning off lights, screens, and the lot when they aren't using them.

But why not in the data center? Did you know that hosts typically use 60%+ of their peak power when idle?

Until recently, I had overlooked configuring my kit to use the vSphere Distributed Power Management ("DPM") feature to manage power consumption and save energy.

With the release of vSphere 6.0 it's a good time to review and take deeper look into the capabilities and benefits of this feature.

Customization of vRealize Automation 6.2.x Email Notifications

User Experience ("UX") focuses on the intimate understanding of your users. What is it that they need or desire, what do they value, what are their abilities, as well as their limitations?

As you embark upon the journey to the software-defined data center (SDDC), think and architect in terms of the user experience in addition to "boxes and arrows."

• What are the desired UX outcomes for those consuming the service(s)?

• Have you considered the UX in terms of its usefulness, usability, desirability, accessibility, credibility, and its value?

In addition to fundamental tenant and business group designs, entitlements and service catalogue designs, one such area for UX consideration is the messages provided to those consuming services of the software-defined data center.

For a moment, imagine you are providing automated infrastructure delivery to multiple business segments of a large media and entertainment organization, each with their own distinct brand. The segments are built upon their individual brand and identity.

• Do you centrally brand the service that you offer or do you tailor the service to each tenant business segment?

• How would this change if instead the services were used to provide automated infrastructure delivery only to your IT Operations team and not direct end users?

On an Organization's Cultural DNA

Have you ever stopped to think about what makes working for your organization appealing?

Perhaps you have wondered why you feel that you are on a different frequency than the rest of the organization?

When Yahoo recently announced that Marissa Mayer would become the Chief Executive Officer there was a great deal of commentary - both speculation and excitement. One remark from Netscape co-founder Marc Anderson I found to be particularly insightful and compelling. Anderson stated that Yahoo had appointed a "product-centered CEO" in Mayer rather staying the course with an interim "sales-centric CEO."

Anderson's insight highlights the fundamentals of what an organization wants to be and the how its culture supports the philosophy. It's apparent in every industry that there are successful organizations with different or even unique philosophies and cultural structures. Take for example the "technology market' in which EMC is known for its sales culture; Google for its scientific engineering culture; Amazon for its supply-chain culture; HP and Xerox for their operational cultures; and of course, Apple for its design and marketing cultures. I have personally have customers in markets that have cultures defined by customer experience as well as healing ministries.

On Principles of Applications

As discussed previously, principles are high level statements of the fundamental values that guide business and technology decision-making and activities and are the foundation for architecture, standards, and policy development. Principles are stable enough to withstand technological and process changes but timely enough to maintain a clear relevancy with markets, policy, program, and management changes.

Principles consist of the principle statement, rationale, and implications. Though the wording for principles should remain consistent, the rational and implications will evolve over time, as an organization responds to factors such as the current IT environment, internal initiatives, external forces and markets, and changes in mission, vision, and strategic plan.

In my prior role as an Enterprise Architect, I used the following Principles for the foundation of the Enterprise Applications. Even with the changes in the industry since I last wrote these  - public, private and hybrid cloud computing, dev-ops, etc - these principles have been steadfast.

IT Governance and the Software-Defined Datacenter

As an organization matures in its journey towards IT-as-a-Service, it becomes increasingly apparent that this is unachievable without increased workload virtualization.

An organization must adapt its IT Governance and adopt a "virtualization first" policy for application workloads. Only then will they be on the path tp realize the full potential of the software-defined datacenter.

This governance process is one in which through which all workloads (net-new, or refreshed) will be deployed as or on virtual machines unless exempted through an virtualization candidate criteria or through an exception process with appropriate override authorization. Any workload, is subject to the governance process - for example, Mission Critical, Business Critical, Business Important or Supporting Function workloads.

On the Principals of Data Management

To be clear, this is not an article about technology. Rather, it is about the organizational, cultural and strategic factors that must be considered to improve the management of data, or information, within organisations.

There are two types of data: structured data and unstructured data.  Structured data refers to data that is kept and managed through database management systems.  Unstructured data refers to data refers to information that either does not have a pre-defined data model and/or does not fit well into relational tables. Unstructured information is typically text-heavy, but may contain data such as dates, numbers, and facts as well.

Effective information management is not simple, but this article draws together a number of ‘critical success factors’ for management of structured data for business transaction processing at or on behalf of an organization. These do not provide an exhaustive list, but do offer a series of principles that can be used to guide the planning and implementation of data management activities. While there is some overlap with business intelligence best practices, these principles do not universally apply to data kept for analytical processing in data warehouses.

On Standards. Domain Teams, and Working Groups

The goals of an Enterprise Architecture Program standards process should be:

• Technical excellence,
• Adoption of proven technology in the environment,
• Clear, concise, and easily understood documentation,
• Openness and fairness,
• Timeliness and
• Organization-wide distribution and use.

To that end, organizations should create procedures that are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Enterprise Architecture standards. At each stage of the standardization process, a specification should repeatedly discussed and its merits debated in open meetings and via community discussion in an Enterprise Architecture Program Community.

There are two, primary development processes and documentation sources for Enterprise Architecture Program standards that I recommend.

1. Domain Teams and Ad-Hoc Working Groups
2. Requests for Comments (RFC).

Let's take a look at the concept of Domain Teams and Ad-Hoc Working Groups.

Enterprise Architecture Domain Teams and Ad-Hoc Working Groups

Enterprise Architecture domain teams are convened by the Enterprise Architecture Office to develop standards and guidelines for information systems. The work of the domain teams is consensus-based. The domain teams produce reports that include recommended principles, architecture patterns and bricks, and recommendations for action.

The Enterprise Architecture domain teams are temporary teams established to develop Enterprise Architecture artifacts within a specific domain of the Enterprise Architecture. For example, a domain team may be assembled to validate a data model, which is a specific model of the Information Architecture. Or, a domain team may be assembled to develop an architecture brick that lists approved standards for a specific technology such as enterprise level database management systems, web-servers or operating systems.

Another method for documenting Enterprise Architecture standards and best community practices is the Request for Comments (RFC) series.  Any stakeholder or working group can propose a new standard or best community practice using this document series.

The process by which domain teams and working groups develop Enterprise Architecture artifacts is one based on consensus. As illustrated in the sections below, domain expert teams and working groups follow a structured process for reaching consensus.

This process ensures cross-organizatio representation, consensus, and alignment.

At a high-level the process is as follows:

1. Identify the Need for a New or Revised Standard, or Best Practice

Most of the time a stakeholder request (individual or governing body) leads to the identification of a need to establish or update a standard. However, there are other ways a need is identified. For example, the Enterprise Architecture Office may initiate an internal project that requires the organization-wide perspective that domain teams provide. Or, it is possible that the Requests for Comments (RFC) process is not able to produce a standard, in which case the Enterprise Architecture Office may decide to establish a domain team.

After the need is identified, the Enterprise Architects may determine that a domain team is the most appropriate standards development process to meet the need.

Exit Criteria:

• The Enterprise Architects determines a domain team should be established.
• Stakeholders or Enterprise Architects determine a working group should be established.

2. Establish the Team

Once the Enterprise Architecture Office determines that a domain team will be convened, they will define the scope of the domain team. Then, a formal request is sent to technology business unit directors and/or manager and other relevant stakeholders (as determined by the Enterprise Architecture Office) to nominate members for the domain team. The Enterprise Architecture Office then selects the team members.

Because all technology business units are invited to participate in the domain team process, it is assumed the business units have delegated decision-making authority to their respective representatives. Therefore, it is assumed that the domain teams’ recommendations have been vetted by the business units.

A working group can also be convened to develop a standard or best practice. Working groups are comprised of stakeholders who may include individuals, groups, and organizations. Contributions from working groups may be unsolicited.

Exit Criteria

• Scope of the domain team or working group is defined.
• Formal request is sent to business unit directors and/or manager relevant stakeholders for nominations.
• Domain team members are selected.
• Invitations are sent to domain team members, meetings are scheduled and rooms secured.

3. Conduct the Team

The domain team or working group begins its work with a formal orientation, or training, kickoff session, during which all members are informed of the work to be accomplished by the team and the plan to accomplish it. The domain team or working group then begins its work. The following are the basic steps each domain team or working group performs to develop their recommendations:

• Understand the current state for the team’s technology area of focus. (For teams that are selecting technology standards this will be defining the current baseline for the specific technology area [i.e., technical domain]).
• Establish or validate guiding principles.
• Finalize the decision criteria the team will use to make its decisions.
• As appropriate, conduct market research to ensure a complete scan of all available products and technologies within the technical domain, and understand the strengths and weaknesses of each vis-à-vis the decision criteria.
• As appropriate, write and issue a Request for Information (RFI) so that all vendors have an opportunity to be included in the evaluation process.
• Deliberate to achieve consensus based on analysis of available information (i.e., current baseline, market research).
• Develop recommendations.
• Compile the team’s next steps and final recommendations.

Exit Criteria

• Meetings are conducted.
• Proposed artifacts are either updated or created (e.g., principles, bricks and patterns.)
• Draft executive briefing is created.
• Domain team checklist is updated.

4. Produce Team Products

After the domain team or working group completes its analysis and finalizes its recommendations, it documents its recommendations in the form of a summary presentation, which the team will present to the Enterprise Architecture Governance Committee or other governing bodies as needed.

Exit Criteria

• Final executive briefing is created (domain team and working group.)
• Draft RFC completed (working group only).

5.a Execute the Approval Process for Working Groups

During this step the appropriate decision making authority(ies) review the working group's recommendations and either approve or reject the working group's proposed standard; or request further analysis. The RFC author then incorporates recommendations, if any, into the final RFC.

Exit Criteria

• A finalized standard or best practice.
• An approved standard or best practice.

5.b Execute the Approval Process for Domain Teams

During this step the appropriate decision making authority(ies) review the domain team’s recommendations and either approve or reject the domain team’s recommendation; or request further analysis.

The IT Management Committee Enterprise Architecture Subcommittee reviews the domain team reports, develops comments and recommendations on the disposition of the domain teams’ findings, and forwards the reports with their recommendations and findings to the Enterprise Architecture Governance Committee. The Enterprise Architecture Governance Committee is the approval authority for the architecture recommendations contained in the reports. The IT Governance Committee is the final authority on disputed recommendations from the domain teams’ findings and recommendations.

Exit Criteria

• A finalized standard or best practice.
• An approved standard or best practice.

6. Publicize the Approved Results

The Enterprise Architecture Program publishes the approved changes online to the Enterprise Architecture Program Library and notifies all Enterprise Architecture Program stakeholders.

Exit Criteria

• Update to the Enterprise Architecture Program website with the results and artifacts of the domain team (e.g., principles, bricks and patterns, et al.)
• Communicate to stakeholders about changes.
• Participants recognized.