There is stateless and stateful master.
For stateless master, you should be able to switch instances. For stateful master, it is a little bit complicated, it might be good to keep EBS snapshot, but the snapshot is not online replica, that you might need to do some manual work to recover from failure.
But those are only from the point of the view of individual instance, the configuration of master(s) might be recorded somewhere else, eg zookeeper, that you also need to refresh configuration afterwards if needed.
If Director is down, then your clusters will still function normally. If you are using pay-as-you-go licensing (a.k.a. usage based billing), then Director should be kept running so that it can gather billing data. Otherwise, you can leave Director shut off unless you want to use it.
If you need to replace your Director instance, you can install Director on a new instance and then provide it access to the old Director's database. For MySQL, that involves the usual configuration for Director. For H2, you must copy the state.h2.db file, usually in /var/lib/cloudera-director-server/state.h2.db, from the old Director instance to the new one. For either scenario, you can also restore the database from a backup if necessary.
If you made any custom configuration changes to the old Director instance, in the application.properties file, then you should also carry them over to the new instance.
Director does not have a mechanism to automatically learn about clusters that are already in existence, either built by a prior Director instance or manually. That's one reason it's important to have database backups.
As I stated in a previous reply, replacing a Cloudera Manager instance is possible but complex, and isn't a first-class feature of Director.
If you find yourself in a situation where you regularly need to destroy and recreate instances, whether for Cloudera Manager or cluster services, then you should consider using transient clusters and storing your data on persistent storage services like S3 or ADLS. Then you can tear down clusters and create new ones without the complexities of in-place instance replacement.
Hello Bill ,
We have migrated the CM to a new instance.Using few tricks and director crash shell we were able to migrate the CM to a new instance.
Have anyone tried to migrate KTS instances on AWS .We cannot keep the same ip of the instances as recommended by cloudera .So can anyone share the steps where we migrate the KTS instance to a new instance with different ip as compared to previous instance ip.