Dashboards in Ceph have always been a bit of a problem. In the past, I tried first to deploy and run Calamari, but it was a complete failure. I talked about my disgraces in this blog post, and there I also suggested a way better solution: Ceph Dash. But now with the release of Luminous, Ceph is trying again to have its own dashboard. Will it be good this time?
In my two previous posts about the new Ceph 12.2 release, named Luminous, I first described the new Bluestore storage technology, and I then upgraded my cluster to the 12.2 release. By default, Ceph can run both OSD using Filestore and Bluestore, so that existing clusters can be safely migrated to Luminous. On the long run, however, users who have previously deployed FileStore are likely to want to transition to BlueStore in order to take advantage of the improved performance and robustness. However, an individual OSD cannot be converted in place. The “conversion” is, in reality, the destruction of a Filestore and the creation of a Bluestore OSD, while the cluster takes care every time of evacuating the old OSD, replicate its content into other OSDs, and then rebalance the content once the new Bluestore is added to the cluster.
After the release of the latest version of Ceph, Luminous (v12.2.x), I read all the announcements and blogs, and based on the list of new interesting features as Bluestore, I decided to upgrade the Ceph cluster running in my lab. This blog shows you the step by step procedure to upgrade a Ceph Jewel cluster to Luminous.
With the release of Ceph Luminous 12.2 and its new BlueStore storage backend finally declared stable and ready for production, it was time to learn more about this new version of the open-source distributed storage, and plan to upgrade my Ceph cluster.
Many software solutions allow for sending reports, warnings, alarms and many other communications via email. This is a great feature to keep track of what’s happening to your installations without having to log into all of them, but having an email server at our disposal these days is not so common anymore. that’s what happened to me last week, and since I was tired to use my personal Gmail account to send myself emails, I decided it was time to find a different solution and to test AWS SES.
In the last weeks I migrated my personal lab to a new location, with new servers and all. I took the opportunity to rebuild some of the test machines I had in my previous one, but one cumbersome and boring task is always to recreate the virtual machines used to do demos, where different applications are deployed and configured to make the demo more “real”; things like Oracle databases, websites, file servers and so on. As both the platforms at source and destination use VMware vCloud Director, I took this opportunity to learn more about migrating vApps from one vCloud to the other, using Veeam Backup & Replication.
If you have just deployed vCloud Director over NSX , it may happen that during the creation of a new VCD network, the operations fails with the error “Cannot deploy organization VDC network; Make sure vShield Manager infrastructure is properly configured and there are segment IDs available.” In this case, you need to change the configuration of the NSX transport zones from Multicast to either Hybrid or Unicast.
For a project I’m working on these weeks, I’ve been asked to demonstrate how an external system (a Cloud Management Platform, an Automation tool, else) can automatically create backups for some specific virtual machines without interacting with the Veeam console. This blog post will show you how, using vSphere Moref IDs.