Nexus

By:Chris Colotti In the first postI talked about the basic architecture of a large scale hybrid cloud build out, as well as integrating an on premises view environment into the vCHS hybrid cloud. We extended that Horizon View environment into the vCloud Hybrid Service by adding security servers and global load balancing on the top […]]> By:Chris Colotti

In the first postI talked about the basic architecture of a large scale hybrid cloud build out, as well as integrating an on premises view environment into the vCHS hybrid cloud. We extended that Horizon View environment into the vCloud Hybrid Service by adding security servers and global load balancing on the top layer. You may be asking yourself “why” did we do that? Well, the ultimate goal of building this out was to mesh together vCloud Hybrid Service – Disaster Recovery and desktops to access those applications. With the next stage we set out to replicate an internal only application to vCHS-DR and use DaaS on vCHS to give the users access to it once it was failed over.

The Use Case Background

Before we go into the architecture solution we need to understand the problem we are trying to solve. Many times in the past I have shown how you can fail over public facing applications. However, not every application is web-based, public facing, or of a “Next Generation” architecture. In a lot of cases many applications are still internal only and although may be web based, need a desktop on the corporate side to access it. This is also the case for legacy fat client applications. So the goal in this architecture was to show how a user can connect to an application on premises and also connect to that same application once vCHS-DR is invoked to fail it over. The solution will comprise a few components for illustration, refer to the original overview diagram to understand all the connection points.

On premises Horizon View Desktops previously configured

On premises “Wiki” based application with a local DNS Entry

On premises AD/DNS Servers

vCloud Hybrid Service – Disaster Recovery running on the Wiki server ONLY

VMware Horizon DaaS on vCHS

IaaS based AD/DNS with VPN connection to the DR Cloud

Cloud to Cloud VPN from Horizon DaaS Cloud to vCHS-DR Cloud

Access to External DNS system

A Horizon View Desktop Client

For the purposes of continuing we will assume that the VPN’s and networks are already configured and replication is running on the Wiki Server. We will also assume from the previous article that the desktop image used for Horizon View on premises is available and ready to synchronize with the new Horizon DaaS cloud. In order to make this all work we need to first ensure the same desktop image is available in DaaS on vCHS for the customer. We will double click into a few of the virtual data centers above later on.

Synchronizing View and DaaS Images with vCloud Connector

For ease of deployment we created our Horizon View on premises desktop image in vCenter. We set it up the way we wanted and then used vCloud Connector Content Sync to push a copy of that up to our DaaS on vCHS cloud. This way we are able to subscribe the DaaS catalog to the vCenter version of the image. vCloud Connector catalog sync then ensures that the DaaS cloud has the same copy available to use. This is not required and there is other DaaS related things you need to do to utilize the image, but we won’t go into that. The concept is just to build one image and sync to the cloud(s). If you want to learn more about Content Sync with vCloud Connector you can watch this video. Honestly it’s easy to setup and takes care of ensuring the image is always in sync. Once you have the image in cloud you can use the admin tools of Horizon DaaS on vCHS to create and deploy a desktop pool with the exact same image.

The Fail Over Process (Run Book)

In normal running conditions, the user would connect to view.companyname.com with their Horizon View Client, access their corporate desktop and get to the Wiki Application using http://Wiki01/ from a desktop browser. In order to ensure the client can get to the same application during failure we need to invoke a process such as this:

Failover the Wiki Application to the vCHS-DR cloud

Re-IP the application in the new cloud and power on

Update the local DNS Servers in the IaaS cloud for the Wiki Entry

Re-Direct External DNS for view.companyname.com to point to the DaaS Cloud instead on on Premises View

Clients can then log in and access the same application, 100% cloud based on desktop and IaaS.

For illustration purposes the logical diagrams below show the on premises environment along with the disaster recovery, and IaaS environments. Remember that the assumption here is all these have the proper cloud to cloud VPN’s and firewall rules setup for network connectivity per the first image.

Below is the On Premises logical architecture. Notice the desktops are are available behind Horizon View and can connect to “WIKI01″

Below is the Dedicated Las Vegas IaaS cloud that is where the AD/DNS is running for access to directory and name services once fail over occurs. Recall that VPN connections here are in place between the DaaS cloud and the vCHS-DR cloud for access to these services.

Below is the Dedicated Las Vegas DaaS tenant logical architecture. You can see the dtRAM gateways in place on the internet passing connection to the DaaS based desktops in vCloud Hybrid Service. Remember this cloud is connected via VPN to the vCHS-DR cloud so it can access the application below upon fail over.

In the Texas Disaster Recovery Cloud shown below, we can do a full fail over or a test fail over. In each case the WIKI01 server will be connected to one of the two networks. Once it is given a new IP address and DNS is updated the DaaS desktops will be able to connect.

Using External DNS To Manage Connectivity

In order to quickly re-direct a user’s View Client from on premises Horizon View to the DaaS desktop and making it transparent to them you need to get creative. In my case I created the following External DNS records to support this use case.

view.dyn.companyname.org = Public IP of View Secure Gateway (A-Record)

daas.dyn.companyname.org = Public IP of Horizon DaaS dtRAM Gateway(A-Record)

view.companyname.org =view.dyn.companyname.org (CNAME 30 Second TTL)

If you are an avid user of DNS for cases like this you should be able to see why I did this. During normal operations the users always connect to view.companyname.com in their client. However, in a disaster event you FLIP the CNAME to use the daas entry on the back end and when the client connects it’s completely transparent to them they are now on a DaaS cloud based desktop. Pretty simply a clean and easy way to manage this step in the run book.

The Role of SSL Certificates For Clients

Something you want to make sure of in this setup so that all clients, both desktop and tablet based work, is that you need to use proper certificates. You have really two options here to maintain the transparency to the user

Install the SSL certificate for view.comnpanyname.com on all View Security Servers AND all the DaaS gateway servers.

Use a wildcard certificate on all the servers

In either case the client is always connecting to “view.companyname.com” so when you flip between Horizon View Servers and DaaS gateway servers, you need the client to be able to authenticate the cert with the same name. The goal here is to make it easy for the end user by not requiring them to change URL’s for their client.

Example Fail Over Video

COMING SOON!

Summary and Conclusions

My entire goal in life with this very extensive lab setup is simply to prove that you can use vCloud Hybrid Service not only for IaaS, DaaS, and DR…..but most importantly you can pull all the parts together into one enterprise level architecture. Instead of using vCHS-DR on the desktops themselves save yourself time and effort. Focus on the applications for DR along with the infrastructure and just leverage vCHS based desktops in Horizon DaaS to connect to those applications you have failed over.

via VMware Blogs http://bit.ly/1qM4qay

Read More Add comment

#Howto repair a crashed #WordPress #database table

By 0x000216

Read

0 Comments

A WordPress database may experience failure and corruption under various circumstances. One of common problems with it is "crashed database." When that happens, you will find the following error in WordPress error log:

WordPress database error Table './my_home/wp_posts' is marked as crashed and last (automatic?) repair failed for query SELECT post_date_gmt FROM wp_posts WHERE post_status = 'publish' AND post_type IN ('post', 'page', 'attachment') ORDER BY post_date_gmt DESC LIMIT 1 made by require('wp-blog-header.php'), wp, WP->main, WP->send_headers, get_lastpostmodified, get_lastpostdate, _get_last_post_time

The symptom of such table crash varies. Depending on which table was crashed, your WordPress blog may malfunction differently. If a crashed table is 'wp_posts' table which contains a list of posts, you will not see any post in your blog.

Why a MySQL Table Crash?

There may be different reasons, but typically when mysqld or the host where mysqld is running is forcibly shut down in the middle of a database update, a database crash can be triggered. In the rest of the tutorial, I will showhow to repair a crashed WordPress MySQL database table.

Method One

If you are using a shared web hosting, typically you will have access to Cpanel, which allows you to repair a database through Cpanel web interface.

On MySQL Databases" page, you will find "Repair DB" option under "Modify Databases" section.

Choose the database which contains a crashed table, and click "Repair DB" button. If repair is successful, you will see the status of every table as "OK".

my_database.wp_oiopub_tracker_visits OK
my_database.wp_options OK
my_database.wp_postmeta OK
my_database.wp_posts
error : Keyblock size at page 13001728 is not correct. Block length: 532 key length: 2
Error : Incorrect key file for table './my_database/wp_posts.MYI'; try to repair it
error : Corrupt
---------
After repair:
----
my_database.wp_oiopub_tracker_visits OK
my_database.wp_options OK
my_database.wp_postmeta OK
my_database.wp_posts OK
my_database.wp_sharebar OK
my_database.wp_term_relationships OK

Method Two

If you have root access on the host (e.g., VPS) where a MySQL sever is running, you can try command-line interface to fix the crashed database table.

For a MyISAM-type database, you can fix a crashed table with a command-line utility called myisamchk. This utility comes with MySQL server installation.

First, stop MySQL server.

$ sudo service mysql stop (Debian/Ubuntu)
$ sudo service mysqld stop (CentOS/RHEL)
$ sudo systemctl stop mysqld.service (Fedora)

Then use this command to fix a particular table.

$ cd /var/lib/
$ sudo myisamchk -r -v -f mysql//

Finally, start MySQL server again.

source

Read More Add comment