Re: [OmniOS-discuss] RSF-1 and Zones
All,
I'm answering my own question here, but, a few other users reached out to me
about it so I'm posting my own crafted solution below which I've found to work
very well with my particular setup.
The key of making an HA zone (assuming RSF-1 is already working properly) is to
configure both/all nodes with the zone making sure they point to the shared
storage and making sure all vnic or other networking is already in place (and
make sure theres no naming conflicts). If you update the zone configuration on
one node you need to do it to all of them so when a failover occurs you don't
end up with a different config. I didn't bother automating that part since that
can be a tricky issue that adds complexity that I don't need in my case.
Here's the core of the failover logic needed:
In /opt/HAC/RSF-1/etc/rc.appliance.c/ add these scripts:
First, a kill script for ONLY the related zones on the shared storage going
down. RSF-1 is kind enough to give us an exported variable RSF_SERVICE we can
extract some important info from :D
K70_zones
#!/bin/bash
SERVICE=${RSF_SERVICE:-"servicename"}
# halt related non-global zones referencing failing service
ZONES=$(zoneadm list | egrep -v '^global$')
while read ZONE; do
zonecfg -z $ZONE export | grep "$SERVICE"
[[ "$?" == "0" ]] && zoneadm -z $ZONE halt
done <<< "$ZONES"
And a start script to attach and bring up any/all accessible/attached/installed
zones:
S70_zones
#!/bin/bash
# attach configured zones
CZONES=$(zoneadm list -c | egrep -v '^global$')
while read ZONE; do
zoneadm -z $ZONE attach -F
done <<< "$CZONES"
# boot installed zones
IZONES=$(zoneadm list -c | egrep -v '^global$')
while read ZONE; do
zoneadm -z $ZONE boot
done <<< "$IZONES"
There's obviously room for improvement, but, this is all I need in order to
make my LX zones (hosting beegfs storage servers) highly available for our HPC
cluster :)
If anyone has any suggestions to make this better, I'm all ears.
Michael
> On Apr 18, 2017, at 1:35 PM, Michael Talbott wrote:
>
> Anyone out there use RSF-1 ( http://www.high-availability.com
>
Re: [OmniOS-discuss] The Future of OmniOS
So, there you have it ... software is not free, and for something as complex and slick as OmniOS, there is serious money involved in keeping it at its current level. It seems that OmniTI has not managed to get this message across to the many organizations relying on OmniOS to run their Servers. Robert has suggested that he hopes that 'the community' will take up the maintenance of omnios in the future ... but I wonder ... now that we know what is going to happen. Do you think your organisation would be prepared to spend some 'real bucks' on keeping OmniOS maintained professionally? I think we would be looking at something like ~500k USD per year. For 1-2 People to continue running the show. I have setup a chat on Gitter ... https://gitter.im/PostOmniOS/Lobby lets meet there and discuss. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch t...@oetiker.ch +41 62 775 9902 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] OmniOS bloody update -- countdown to r151022
> On Apr 20, 2017, at 11:08 PM, Dan McDonald wrote: > > Speaking of debugging, a few of the debugging items involve the installer > ISO, so there will not be an ISO update with this bump. Debugging of the installer went better than expected, AND there's a better Timezone selector now thanks to Jens Bauernfeind. This page: http://omnios.omniti.com/wiki.php/Installation now has updated ISO, USB-DD, and ZFS receive images for the new bloody. Until r151022 ships, I'm still hard at work, so please keep banging away on these as I am. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] The Future of OmniOS
As both a home hobbyist user of OmniOS and a paid support user of OmniOS at my day job, I'd first like to thank you guys for putting together a great operating system that has served me well over the years and I hope will continue to do so. However, I would like to clarify your stance when you say you are "suspending active development" and that r151022 will be the "final release". Per your historical release cycle: https://omnios.omniti.com/wiki.php/ReleaseCycle r151022 was to be an LTS release with security/bug fix support through H1 2020. While there will be no further releases of OmniOS from OmniTI, will you continue to back port fixes and fix issues in r151022 through that timeline, or will it be released as is and then be up to the as yet undeveloped community to do so? We currently have critical production systems deployed, systems whose deployment was only approved by management due to the availability of commercial support (the wisdom of such a perspective we will not discuss), and this sudden development is potentially going to leave us in quite a pickle. While I certainly can't dictate to you how to run your business, it would have been much easier on your customers had you made this announcement with the release of r151022, and coincided the end of your support offering with the end of life of this last release. Which also ideally would have provided time for an omnios community to have developed and started producing their own releases before the last officially supported omniti version reached sunset. > -Original Message- > From: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] > On Behalf Of Robert Treat > Sent: Friday, April 21, 2017 7:07 AM > To: omnios-discuss > Subject: [OmniOS-discuss] The Future of OmniOS > > Five years ago, when we first launched OmniOS, we did it out of a > direct need to push forward the OpenSolaris ecosystem that we had > built into the core of several parts of our business. At the time, the > illumos community was still rather new and taking direct control of > our path forward was a solid next step; we had already built many of > the pieces in-house that we needed to produce a complete operating > system distribution, and our experiences with open sourcing software > we worked on had been generally very good. > > While we didn't know quite what the reaction would be, there were two > things internally that guided us as long term factors in our decision. > First, as we have done for other open source software, we thought it > made sense to offer commercial support for OmniOS, but there was no > desire to "pivot" OmniTI to be an operating system vendor. We like the > world of building and running high-scale software and infrastructure > and that's where we wanted to stay. Hand in hand with that was the > second idea, that while we felt it was important for us to take the > first initial steps, in the long term we really would prefer that > OmniOS become an open source project maintained by its community > rather than remain as the open source product of a single commercial > entity (think Debian vs Red Hat, if that helps). > > Five years later, we are proud to see that this software has been > accepted by a wide group of companies and end users, and we think this > has been a boon for the illumos community, who are the shoulders we > build upon. When you see companies from all sectors and industry, both > small and some orders of magnitude larger, using the technology you > put forward to build even further; well, it's great to have an impact. > > However, even with the success we have had, there is one area we have > failed to make progress on, which is the goal of making OmniOS > community operated. There are many factors why this hasn't happened, > but ultimately in five years of both ups and downs within OmniTI, I am > left to conclude that if we are ever to change the nature of OmniOS, > we need to take a radical approach. > > Therefore, going forward, while some of our staff may continue > contributing, OmniTI will be suspending active development of OmniOS. > Our next release, currently in beta, will become the final release > from OmniTI. We are currently going through steps to remove any build > dependencies on OmniTI or its infrastructure, and we've made some > steps towards determining what potential resources we currently > control which could be turned over to an open source community should > one emerge; for example, we can continue running OmniOS mailing lists > from OmniTI, but would eventually like to see those transitioned to > something operated by the community itself. > > To be clear, our goal is not to abandon OmniOS, but to divest OmniTI > from the open source project in order to spur others to participate > more. We still run quite a bit of infrastructure on OmniOS and expect > to continue contributing, but the current model does not work for > OmniTI nor do we believe it is healthy for the OmniOS community
[OmniOS-discuss] The Future of OmniOS
Five years ago, when we first launched OmniOS, we did it out of a direct need to push forward the OpenSolaris ecosystem that we had built into the core of several parts of our business. At the time, the illumos community was still rather new and taking direct control of our path forward was a solid next step; we had already built many of the pieces in-house that we needed to produce a complete operating system distribution, and our experiences with open sourcing software we worked on had been generally very good. While we didn't know quite what the reaction would be, there were two things internally that guided us as long term factors in our decision. First, as we have done for other open source software, we thought it made sense to offer commercial support for OmniOS, but there was no desire to "pivot" OmniTI to be an operating system vendor. We like the world of building and running high-scale software and infrastructure and that's where we wanted to stay. Hand in hand with that was the second idea, that while we felt it was important for us to take the first initial steps, in the long term we really would prefer that OmniOS become an open source project maintained by its community rather than remain as the open source product of a single commercial entity (think Debian vs Red Hat, if that helps). Five years later, we are proud to see that this software has been accepted by a wide group of companies and end users, and we think this has been a boon for the illumos community, who are the shoulders we build upon. When you see companies from all sectors and industry, both small and some orders of magnitude larger, using the technology you put forward to build even further; well, it's great to have an impact. However, even with the success we have had, there is one area we have failed to make progress on, which is the goal of making OmniOS community operated. There are many factors why this hasn't happened, but ultimately in five years of both ups and downs within OmniTI, I am left to conclude that if we are ever to change the nature of OmniOS, we need to take a radical approach. Therefore, going forward, while some of our staff may continue contributing, OmniTI will be suspending active development of OmniOS. Our next release, currently in beta, will become the final release from OmniTI. We are currently going through steps to remove any build dependencies on OmniTI or its infrastructure, and we've made some steps towards determining what potential resources we currently control which could be turned over to an open source community should one emerge; for example, we can continue running OmniOS mailing lists from OmniTI, but would eventually like to see those transitioned to something operated by the community itself. To be clear, our goal is not to abandon OmniOS, but to divest OmniTI from the open source project in order to spur others to participate more. We still run quite a bit of infrastructure on OmniOS and expect to continue contributing, but the current model does not work for OmniTI nor do we believe it is healthy for the OmniOS community as a whole. Could this mean the end of OmniOS? We can't guarantee it won't. For that matter, recent user data shows that a majority of the community still uses OmniOS primarily as a storage solution, not a platform for high-scale web computing (which was our original intent), so even if a community does form, it could move the project in a direction that doesn't align with our needs. If that happens, we feel comfortable knowing there are several other strong illumos based options available. In the end, while this rip-the-band-aid-off approach is not without risk, it is one we feel is necessary. We hope that most folks will respond to this not with fear but with the understanding that there is now an opportunity to build a broader, stronger community, and we look forward to working with others to make that a reality. Robert Treat CEO https://omniti.com ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkg update fails with ImageNotFoundExeption
Hi Dan, thanks for answering... Am 19.04.2017 um 15:12 schrieb Dan McDonald: Check the contents of the new BE's mount directory. Try this too: pkg -R /tmp/ publisher Same error as above. Do you do anything weird with filesystems that are supposed to be within the BE (like having /var on a different zfs dataset)? Guilty as charged ;) Moved /var/pkg due to space contraints, bad idea if you think about it... thanks again, Paul Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
