I understand that, but I'm not sure your point. If you used ebs, you could stop one instance at a time, swap out your OS drive via new AMI, and start it again attached to your existing data drive, and bounce a whole cluster in a rolling manner, perhaps 5 minutes per node.
If you don't want to change to EBS (a fair position), the approach you're using is reasonable, or you could swap one node at a time by replacing it. I'd probably use your method, but I'd write tooling so it wasn't entirely manual. -- Jeff Jirsa > On May 27, 2017, at 7:13 PM, Surbhi Gupta <surbhi.gupt...@gmail.com> wrote: > > We get the new AMI release with the new OS updates and we are not allowed to > use the old AMI . > > >> On Sat, May 27, 2017 at 7:11 PM Jeff Jirsa <jji...@apache.org> wrote: >> >> >> >> >> On 2017-05-27 18:04 (-0700), Surbhi Gupta <surbhi.gupt...@gmail.com> wrote: >> >> > Thanks a lot for all of your reply. >> >> > Our requirement is : >> >> > Our company releases AMI almost every month where they have some or the >> >> > other security packages. >> >> > So as per our security team we need to move our cassandra cluster to the >> >> > new AMI . >> >> > As this process happens every month, we would like to automate the process >> > . >> >> > Few points to consider here: >> >> > >> >> > 1. We are using ephemeral drives to store cassandra data >> >> > 2. We are on dse 4.8.x >> >> > >> >> > So currently to do the process, we pinup a new nodes with new DC name and >> >> > join that DC, alter the keyspace, do rebuild and later alter the keyspace >> >> > again to remove the old DC . >> >> > >> >> > But all of this process is manually done as of now. >> >> > >> >> > So i wanted to understand , on AWS, how do you do above kind of task >> >> > automatically ? >> >> >> >> >> >> At a previous employer, they used M4 class instances with data on a >> dedicated EBS volumes, so we could swap AMIs / stop / start / adjust >> instances without having to deal with this. This worked reasonably well for >> their scale (which was petabytes of data). >> >> >> >> Other companies using ephemeral tend to be more willing to just terminate >> instances and replace them (-Dcassandra.replace_address). If you stop >> cassandra, then boot a replacement with 'replace_address' set, it'll take >> over for the stopped instance, including re-streaming all data (as best it >> can, subject to consistency level and repair status). This may be easier for >> you to script than switching your fleet to EBS, but it's not without risk. >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >> >> For additional commands, e-mail: user-h...@cassandra.apache.org >> >> >>
