Clustering

MySQL Cluster 7.6 includes new Cluster Configurator

After dealing with Windows performance, I switched to MySQL Cluster Configurator (MCC for short) project. This was quite a change for me having to deal with Python back-end and JavaScript front-end, languages I was not so familiar with.

For the history of the project, please refer to Andrew’s blog post for I will concentrate on changes made in new version.

There are many exciting new features in MySQL Cluster 7.6.4DMR including new MCC. To download MySQL Cluster 7.6.4DMR, please go to Development Releases tab. To see what’s new in 7.6.4DMR, please follow this link.

MySQL Cluster Configurator in short

With a single command launch the web-based wizard which then steps you through configuring, deploying configuration and starting the cluster; to keep things even simpler, it will automatically detect the resources on your target machines and use these results together with the type of workload you specify in order to determine values for the key configuration parameters.
The software is part of the MySQL Cluster package (NDB). To run on Windows, just double click setup.bat – note that if you installed from the MSI and didn’t change the install directory then this will be located somewhere like C:Program Files…MySQLMySQL Cluster 7.6. On Linux, just run ndb_setup from the bin folder.
On Windows, we provide all necessary libraries and the Python while on Linux, you should have Python 2.7 (latest) installed as well as Paramiko 2 or newer. Paramiko will install Cryptography and other required libraries.

If you launch the installer from a desktop environment shell then the first page of the wizard will automatically open in your web browser, if not then just browse to the URL that is displayed on the command line.

Recap: Start the Python web server from shell using setup.bat (Windows) or bin/ndb_setup (*nix), JavaScript front-end will be opened for you in default browser. If it’s not, copy the link from console to your favorite browser. Make sure you have administrator rights on all the hosts you will use in cluster. Also, make sure to have MySQL Cluster installed on all the boxes making up cluster.
There is an extensive help file in /hlp/html directory, please read if you’re new to product.

Who is this software for

Typically, MCC would be used by developers working on Cluster software and people looking for quick evaluation of MySQL Cluster on various hardware configurations including cloud instances.

New version highlights

  • Multiple reusable configurations. Take your configuration with you to work on different boxes.
  • Much safer configuration files allowing for saving passwords/passphrases resulting in full restoration of NDB Cluster from configuration file.
  • Many new options to configure both for NDB Cluster processes as well as for mysqld. Multiple choice options have proper drop-down lists associated.
  • Many new members in Cluster and Host objects. GUI changes to present them.
  • Nodes can have external IP address (to gain access from MCC for example) as well as internal IP address (for faster and safer communication inside cloud deployment or other VPN environment).
  • Extended ways of authentication such as using different username, private key on per host basis, using keys with passphrases and so on.
  • Better detection of running cluster processes and option to stop them even if startup fails.

 

Language choice

JavaScript was obvious choice since it’s common to have GUI run in browser. Due to it’s limitations (none likes browser sniffing around file system), we have back-end web server in Python handling various requests related to files, remote hosts etc. Front and back end communicate via POST messages so it is really important that you protect this communication. For a start, we provide self signed certificates for securing it. If you are testing things in sand-box, you may switch https for http to speed up things.
Recap: Python back end manipulates encryption/decryption, files, connections to local/remote hosts and so on while JavaScript front-end provides GUI in your browser for convenient presentation of configuration options.

Changes

Changes in configuration files and authentication methods:

First change tackled is the configuration. Versions shipped with previous Cluster releases had two major drawbacks; they kept configuration in cookies and could handle just one Cluster configuration which was locked to box where you created it. Keeping Cluster configuration in cookies comes with two major drawbacks; cookies are size-limited and very insecure.
To remedy this situation, we opted for external configuration file saved in current user’s HOME directory (this is done through Python web server that’s running MCC); one configuration per file. The file itself is AES encrypted using passphrase provided in front-end and passed down to Python web server via POST message. Passphrase is then kept in memory for the duration of session. With provided passphrase and file name, Python server sends decrypted configuration back to front-end. Configuration is kept in global.windowname variable for the duration of the session.

This has solved several issues:

  • Configuration now stores all your passwords, passphrases for keys and such allowing for quick and full recreation of Cluster.
  • Extending configuration size allows for per-host credentials. I.e. each host in Cluster can have it’s own way of authentication and set of credentials.

Essentially, when looking for quick and dirty deployment over hosts that use same credentials, it is enough to provide them on Page 2, Cluster Configuration. When working with hosts that have their own separate credentials, you can define them on Host level (Page 3, Add Hosts). We prefer adding hosts on Page 3 via Add Host button to defining them on Page 2 “Host list” box.
Credentials can be:

  • Username/password.
  • Username/Key name.
  • Username/Key name/Passphrase.
  • Key name/Passphrase.
  • Key name.
  • Nothing.

If PATH is not provided along with Key name, ~/.ssh is assumed. If using keys and no key name is provided, ~/.ssh/id_rsa is assumed. So, for authentication using standard private key without passphrase stored in default place, you just need to check “Key based SSH” (Page 2, Cluster level) or “Key-based auth” for particular host (Page 3, Add/Edit Host) checkbox and nothing more. If there are absolutely no credentials at host level, program behaves as in old versions meaning whatever was provided on Cluster level is used.

WARNING: Although asynchronous, call to save configuration changes does take some time to complete. The saving of configuration takes place after pressing “Save&Next” button:

No changes are saved if you close the tab or browser abruptly! After making extensive changes and pressing Save&Next I like to allow for some time for configuration to be saved. If you open debug console, you will see the notification.
If you Cluster is all set up and ready to go and you just want to take one more look at various configuration options, you can use breadcrumb buttons as they do not trigger save method:

Since all credentials are saved, you can skip looking into loaded configuration altogether and go directly to “Deploy configuration” page.
Gotcha: In order to make configurations portable, we had to limit the usage of “localhost”. If you include localhost in your Cluster, you will not be able to add any more remote hosts.
Gotcha: List with available configurations is provided to front-end upon welcome page load so if you add more configurations to your HOME using external tools they will not be shown (unless you reload page or restart entire program). However, if you choose “New Configuration” and provide the name of existing one, the existing configuration will be loaded.
Gotcha: “New Configuration” requires you to provide a passphrase and a confirmation. Reading existing configuration just requires passphrase. Please keep your passphrase(s) safe as there is no way to reverse engineer contents of configuration file without it! Each file/configuration can have it’s own passphrase.
Recap: There can be any number of portable, encrypted configurations now which you can find in your HOME on box running MCC. Each host can have it’s own way of authentication and a set of credentials. We did our best to guess which auth method and credentials to use based on input provided.

Changes in Cluster object (Page 2):

Cluster object has two new attributes:

  • Install MySQL Cluster: Option for installing Cluster on hosts
    NONE: No installation of Cluster will take place (default).
    BOTH: Both DOCKER and installation from REPO will be considered depending on OS and available images. Should both installation mechanisms be available on certain host, we will prefer REPO over DOCKER.
    REPO: For every host in Cluster, the attempt will be made to install Cluster SW from the repository URL.
    DOCKER: For every host in Cluster, the attempt will be made to install Cluster SW DOCKER image.
  • Open FW ports: Check if you need the tool to try to open necessary ports for Cluster processes on every hosts.

Gotcha: In this version “Install MySQL Cluster” is not functional so you need Cluster installed on all hosts beforehand.

Changes in Host object and GUI (Page 3):

Host object has undergone major rework. Host name is now used for external host IP address i.e. IP address at which MCC web server instance can reach that particular host. Host Internal IP refers to that particular host IP address inside VPN. If there is no VPN in play, both IP addresses are the same. We strongly encourage using IP addresses here to skip potential problems with resolving host names.
Authentication, as per above, could be a) using keys or b) ordinary username/password. If you check Key-based auth when Adding/Editing host and provide nothing, ~/.ssh/id_rsa key will be used without passphrase. You can also define alternate user (to one starting MCC) which comes handy when logging in to domains. Each key can have passphrase and you can provide the path to and name of specific key to use for that host.
If you check Configure installation, you will be presented with additional fields relating to repository and Docker image. We do our best to provide you with default values based on OS running on particular host you’re Adding/Editing.

We have also added Show/Hide extended host info toggle button switching between single and double line host info representation.

Changes to Define parameters (Page 5):

We are constantly adding more configurable parameters to keep up with MySQL server and Cluster evolution but this is a moving target so we ask for patience if certain parameter you’d like to configure is missing.
In addition to many new configurable parameters, we have extended a GUI so that, for appropriate options, you get drop-down list of allowed values.

Changes to Deploy configuration (Page 6, last):

The Start and Stop Cluster buttons now behave more intelligently in terms of determining if the Cluster or any of its processes is running and enabling/disabling appropriate buttons.
Previously, if Cluster was stuck in any of the startup phases, you had to terminate MCC and kill all the processes on all of the hosts manually. Now, if you think something is wrong, you can close the progress window and it will give control back to MCC enabling Stop Cluster button which you can then press to stop the stray processes properly. It will also provide you with list of log files which you can then check for problems.
Stopping mysqld process(es) might not work if you changed the credentials from command line.

These changes are available in version 7.6.4DMR and up. We encourage you to try MCC and MySQL Cluster in your environment!

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *