填坑有意思么？
能从坑里爬出来、又把填平有就意思；在坑里蹲着的时候，就很没意思。
而世上最可悲的事情是：次次都上当，当当都一样。相同的坑总掉进去，因为忘了此处彼处有坑。为了怕忘记坑的位置，大魏会经常写填坑记录，并且公众号推送出来，从不藏着掖着。
Anyway，填坑伤身体。大萝卜多吃，坑少填。
言归正传，为什么叫跨年坑？因为OCP的坑从2020年填到了2021年，终于爬出来并彻底填平。下面我们看看填坑的过程。
1.12月23号左右，一套别人装好的OCP交到了大魏手里。
登录、访问都没问题，但是：OperatorHub无法访问。Hub不是一定要用，但本着有病得治的原则，开启了Operator的修复之旅。详见：
升级过程中etcd operator死活升级不上去，用如下方法填坑：
大力金刚指@OpenShift升级etcd operator报错
总之，OperatorHub算是修好了，OCP也成功升级了。记住，此时一起看起来很正常、看起来OCP的病治好了。
2. 三天后OCP在压力测试过程中，MCO配置无法下发。
查看MCP，Master MCP出现问题。
对OCP熟的人都清楚，MCP不好修，能不能修好，很多时候看运气。
总之，MCP被大魏奇迹般地修复了，很开心，详见：
期间大魏还修了一把Image Registry：
3.在随后几天的测试过程中，发现OCP很卡。
卡到什么程度？比如oc get nodes、oc get co，大概4-5秒才有反应。
查看OCP宿主机（安装在两台x86的vSphere），master VM的磁盘延时有几十毫秒的延时，最高到200多毫秒。于是：
申请加FC SAN 1T（全Flash存储，很高端），做VM datastore--->做Storage vmotion，把所有vm迁移到FC SAN---->发现有两个master vmotion总失败--->大魏查看vsphere日志，发现路径频繁切换怀疑有坏盘：
第二天， 请现场技术人去机房一看 ，三个SAS做的raid5 两个亮黄灯
现场技术人员尝试拔插块硬盘触发rebuild， 整个raid直接挂掉。而OCP的两个Master和堡垒机，正好装在这个raid5做的datastore上。
一夜回到解放前。。。。
4.12月31日，决定重装OCP。
硬盘问题定位了，FC SAN也有了，决定重装（现场有技术人员、我远程，一起安装），重装治百病。2020年的坑，别拖到2021年不是？
首先再多申请1T的FC SAN，对原有1T的FC SAN Datastore扩容，这次把所有VM都装在高端存储上，玩把大的。
但是，重装OCP的时候，RHCOS在第一次安装后自动重启，报错如下：
关键句就是：failed to set up standard input: Inappropriate ioctl for device。
这报错大魏没看见过啊，于是谷歌、内网去搜索，无果。
于是开始排查：
FC磁盘不识别？install-config.yaml写错了？时间戳不对？VM的OS类型选的不对？(vSphere里专门有个CoreOS的VM OS类型)、启动参数输入不对？install iso下载的有问题？raw.gz下载的有问题？
NoNoNo,都不是。
这时候，已经是2020年12月31日晚上了，年内的坑肯定填不平了。
5. 2021年1月1日：破案.
大魏所有能想到的可能问题点都排查了，一定是有什么很普通的细节被忽略，一定是！
福尔摩斯说：一切合理的答案都被逻辑排除后，剩下的那个因为主观，所以被贴上“不可能”的标签的答案即为正解。
果然，在意想不到的点，找到了线索！
问题源于：安装OCP的时候，错误地下载了最新版本的openshift-install二进制文件（4.6的），而要安装的OCP的install.iso和raw.gz却是4.5的。
找到这个问题后，火速下载正确版本，进行重装。
很快装好，搞定。
使用FC SAN 环境，OCP反应是飞一样的速度， master的平均磁盘延迟不到1毫秒。
总结：
1.OCP4对网络I/O和磁盘I/O比较敏感，所以生产上最好OCP安装在SSD磁盘或者FC SAN。因为你要知道，OCP在生产上可以要承载上千个业务容器的。保时捷汽车都买了，不应该买几个好轮胎么？
2.以前我看到很多关于OCP4三个Master跨机房部署，实现所谓一个集群的应用多活的讨论，一看就没掉进过坑。
OCP4的etcd，心跳的同步最长不能超过100ms。100数字看起来挺大，对不？但单位是毫秒。也就是说，OCP master之间的网络延迟，不能高于1/10秒！所以，别折腾了，生产以稳定、稳妥为主。想PoC验证可以试试，但大魏不兜底。
对此感兴趣，有疑问的可以参考：
