【云计算】marathon集群如何升级?

Upgrading to a Newer Version

We generally recommend creating a backup of the ZooKeeper state before upgrading to be able to downgrade in case of problems after an upgrade. This can be done by creating a copy of ZooKeeper‘s data directory.

Upgrading a non HA installation

Upgrading to a newer version of Marathon should be executed in the following order:

  1. Tear down the running instance of Marathon.
  2. Install the new version of Marathon.
  3. Start the new version of Marathon and watch the log for a successful start.

Upgrading an HA installation

Upgrading to a newer version of Marathon should be executed in the following order:

  1. Tear down all running instances of Marathon except one. This instance will be the leader.
  2. Install the new version of Marathon on one of the nodes with the old version.
  3. Start the instance with the new version of Marathon.
  4. Stop the last node with the old version. Now the new version of Marathon will take over leadership and becomes active.
  5. Watch the log of this instance for a successful start. There should be no ERROR or FATAL statements in the logs.
  6. Install the new version of Marathon on all remaining nodes with the old version.
  7. Start all other instances of Marathon to build a quorum.

Upgrading to 0.13

Release Notes: https://github.com/mesosphere/marathon/releases/tag/v0.13.0

Tasks keys and storage format in ZooKeeper changed in a backward incompatible fashion. Zookeeper compression is implemented and enabled by default. Older versions will not be able to read compressed entities. Marathon nowuses logback as logging backend. If you are using custom log4j properties, you will have to migrate them to a logback configuration.

Upgrading to 0.11

Release Notes: https://github.com/mesosphere/marathon/releases/tag/v0.11.0

Java 8 or higher is needed to run Marathon, since Java 6 and 7 support has reached end of life. --revive_offers_for_new_apps is now the default. If you want to avoid resetting filters if new tasks need to be started, you can disable this by --disable_revive_offers_for_new_apps.

Upgrading to 0.10

Release Notes: https://github.com/mesosphere/marathon/releases/tag/v0.10.0 Release Notes: https://github.com/mesosphere/marathon/releases/tag/v0.9.0 Release Notes: https://github.com/mesosphere/marathon/releases/tag/v0.8.0

0.8, 0.9 and 0.10 only add new optional fields and do not change the storage format in an incompatible fashion. Thus, an upgrade should not require any migration. You can also rollback at any time in case of errors as long as you do not start using new features. Nevertheless we always recommend a backup of the Zookeeper state.

Upgrading from 0.6 to 0.7

Be aware that downgrading from versions >= 0.7.0 to older versions is not possible because of incompatible changes in the data format. See here for an upgrade guide from 0.6.* to 0.7.0

参考资料:

https://mesosphere.github.io/marathon/docs/upgrade/index.html

时间: 2024-10-14 11:28:23

【云计算】marathon集群如何升级?的相关文章

网时|云计算的集群技术对于传统IDC而言,又有哪些提高呢?

当传统的IDC产品已经不足以满足现在科技的飞速发展时,云计算便应运而生.咱们暂且不论云计算在其他领域的贡献,仅IDC来讲,云计算的集群技术对于传统IDC而言,又有哪些提高呢? 1.服务类型 常用的传统IDC主要包括租用和托管两类.租用是指用户所用的是服务商的设备,放在服务商的机房里,由服务商负责维护:托管是指用户所用的是自己的设备,由服务商帮忙看管,若是设备损坏,与服务商没有关系. 而云计算提供的服务是从基础设施到业务基础平台再到应用层的连续的整体的全套服务. IDC数据中心将规模化的硬件服务器

老nginx集群向tengine集群的升级改造,性能提升数倍

集群服务器使用nginx+fpm(php)的结构,这种结构的性能很大程度的瓶颈在fpm这一层,随着业务发展,访问量的增加,为了保证用户体验,我们在通过各种手段去提升集群的吞吐量和服务质量--机器扩容.业务分池.MC/REDIS的local化等等,做下来看到的效果是明显的,不过量级上的提升还是迫切需要,于是想到了在web服务器上在下下功夫,集群使用的nginx版本有点历史,版本就不说了,不过一直跑的都很健壮,所以没从想过更换,一个简单的事情促使我想测试更换为tengine,那就是worker进程数

kubernetes实战(十六):k8s高可用集群平滑升级 v1.11.x 到v1.12.x

1.基本概念 升级之后所有的containers会重启,因为hash值会变. 不可跨版本升级. 2.升级Master节点 当前版本 [[email protected] ~]# kubeadm version kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac

手动升级kubernetes集群

手动升级kubernetes集群 在我最开始写作本书的时候,kubernetes刚发布1.6.0版本,而kubernetes基本按照每三个月发布一个大版本的速度迭代,为了使用新特性和只支持新版本kubernetes的配套软件,升级kubernetes就迫在眉睫,在此我们使用替换kubernets的旧的二进制文件这种暴力的方式来升级测试集群,若升级生产集群还望三思. 另外,自kubernetes1.6版本之后发布的1.7和1.8版本又增加了一些新特性,参考: Kubernetes1.7更新日志 K

GaussDB T分布式集群部署以及升级指南

本文用四节点部署GaussDB T 1.0.1分布式集群,部署完成后再将其升级到1.0.2版本(直接安装1.0.2版本,在安装过程中会遇到segment fault报错,目前尚未解决).前期操作系统准备工作参考之前的几篇文章. 1.部署分布式集群 1.1 节点信息 各节点信息如下表所示: 1.2 集群参数文件 根据实际情况修改集群参数,或者通过database manager工具生成,内容如下: [[email protected] db]# vi clusterconfig.xml <?xml

Elasticsearch 集群版本升级步骤及注意事项

Elasticsearch 自从1.0.7版本之后,集群各节点的滚动式升级已不需要重启集群,相比之前的升级模式来看,可以非常平滑的渡过升级过程.这里将叙述集群滚动式升级及其注意事项. 1.升级前的准备工作 从Elasticsearch 的官方网站 https://www.elastic.co/downloads/elasticsearch 下载最新版本的Elasticsearch,为了线上方便对数据包的管理,一版选择 .gz.tar 格式或者 .zip 格式文件. 解压缩最新版本文件压缩包到指定

Oracle 11g 管理Oracle 集群

管理Oracle 集群 命令行工具 –crsctl管理集群相关的操作: -启动和关闭Oracle集群 -启用和禁用Oracle集群后台进程 -注册集群资源 -srvctl 管理Oracle 资源相关操作 -启动和关闭数据库实例和服务(dbdao.com oracle 11g OCM培训) 在Oracle Grid安装的home路径下的命令行工具crsctl和srvctl用来管理Oracle集群.使用crsctl可以监控和管理任何集群节点的集群组件和资源.srvctl工具提供了类似的功能,来监控和

docker mesos集群资源调度平台

mesos原理与架构 首先,再次需要强调 Mesos 自身只是一个资源调度框架,并非一整套完整的应用管理平台,所以只有 Mesos 自己是不能干活的.但是基于 Mesos,可以比较容易地为各种应用管理框架或者中间件平台(作为 Mesos 的应用)提供分布式运行能力:同时多个框架也可以同时运行在一个 Mesos 集群中,提高整体的资源使用效率.Mesos 对自己定位范围的划分,使得它要完成的任务很明确,其它任务框架也可以很容易的与它进行整合. 基本单元Mesos 中有三个基本的组件:管理服务(ma

k8s集群一键新加node节点脚本

继推出k8s集群一键升级脚本之后有不少小伙伴还有k8s在线扩容节点的需求,所以本次波哥就又写了一个扩充节点的脚本.明天有时间我再整理一下k8s部署集群脚本,目前是固定版本的,转化成部署任意版本的脚本或许更灵活一些.这样我们部署,升级,扩容三套脚本基本就能搞定k8s日常基础需求了.波哥也可以安心的写小程序后台了. 同样只要是你使用波哥的脚本部署的k8s集群都支持一键扩容哦! 脚本介绍: 跟以往一下我们有个base.config文件,修改上面的参数.这里我写好了自己的例子还有相关注释. 配置完毕后执