首先，管理部门对监控系统维护工作重视程度不够，认为没必要投入太多的人力、物力及财力，因而在管理过程中忽略对监控系统设施的管理，导致系统的后期管理和维护跟不上。
其次是没有一个完备的、有计划性的监控设备维护实施方案。沈阳桃仙国际机场的监控设备数量达上百台，而且分布在整个航站楼的一层、一层夹层、二层以及二层夹层和地下一层，设备的维护是一项艰巨而重要的工作，这些监控设备分类并制定出维护方案，把复杂繁琐的工作变得条理化，明确化。当某个设备出现故障时，专业技术员可以很快调出这个设备的相关技术参数、性能指标等相关资料，并采取针对性的维护措施，有效的提高设备的维护效率。
第三是监控设备的采购中过多的考虑了设备的性价比而忽视了监控系统及设备后期的维护和保养。监控设备品牌过多、产品供应商过多，厂家售后保障措施不到位等等原因，导致监控设备使用一段时间后，设备故障不断、损坏率不断攀升，最终不得不对原有设备进行大面积更新，出现重复投资、浪费严重的现象。
监控设备的维护方法
为了做好监控设备的维护工作，维修中心配备相应的人力、物力（工具、通讯设备等），负责日常对监控系统的监测、维护、服务、管理, 承担起设备的维护服务工作, 以保障监控系统的长期、可靠、有效地运行。
1、维护基本条件
古话说的好，“巧妇难为无米之炊”，对监控系统的维护来说也是一样的道理，对监控系统进行正常的设备维护所需的基本维护条件，即做到“四齐”，即备件齐、配件齐、工具齐、仪器齐。
1) 备件齐
通常来说，每一个系统的维护都必须建立相应的备件库，主要储备一些比较重要而损坏后不易马上修复的设备，如摄像机、镜头、监视器等。这些设备一旦出现故障就可能使系统不能正常运行，必须及时更换，因此必须具备一定数量的备件，而且备件库的库存量必须根据设备能否维修和设备的运行周期的特点不断进行更新。
2) 配件齐
配件主要是设备里各种分立元件和模块的额外配置，可以多备一些，主要用于设备的维修。常用的配件主要有电路所需要的各种集成电路芯片和各种电路分立元件。其他较大的设备就必须配置一定的功能模块以备急用。这样，经过维修就能用小的投入产生良好的效益，节约大量更新设备的经费。
3) 工具和检测仪器齐
要做到勤修设备，就必须配置常用的维修工具及检修仪器，如各种钳子、螺丝刀、测电笔、电烙铁、胶布、万用表、示波器等等，需要时还应随时添置，必要时还应自己制作如模拟负载等作为测试工具。
2、设备维护中的一些注意事项
在对监控系统设备进行维护过程中，应对一些情况加以防范，尽可能使设备的运行正常，主要需做好防潮、防尘、防腐、防雷、防干扰的工作。
1)防潮、防尘、防腐
对于监控系统的各种采集设备来说，由于设备直接置于有灰尘的环境中，对设备的运行会产生直接的影响，需要重点做好防潮、防尘、防腐的维护工作。如摄像机长期悬挂于棚端，防护罩及防尘玻璃上会很快被蒙上一层灰尘、碳灰等的混合物，又脏又黑，还具有腐蚀性，严重影响收视效果，也给设备带来损坏，因此必须做好摄像机的防尘、防腐维护工作。在某些湿气较重的地方，则必须在维护过程中就安装位置、设备的防护进行调整以提高设备本身的防潮能力，同时对高湿度地带要经常采取除湿措施来解决防潮问题。
2)防雷、防干扰
只要从事过机电系统的维护工作的人都知道，雷雨天气一来，设备遭雷击是常事，给监控设备正常的运行造成很大的安全隐患，因此，监控设备在维护过程中必须对防雷问题高度重视。防雷的措施主要是要做好设备接地的防雷地网，应按等电位体方案做好独立的地阻小于1欧的综合接地网，杜绝弱电系统的防雷接地与电力防雷接地网混在一起的做法，以防止电力接地网杂波对设备产生干扰。防干扰则主要做到布线时应坚持强弱电分开原则，把电力线缆跟通讯线缆和视频线缆分开，严格按通信和电力行业的布线规范施工。
3、具体如下：
I. 每季度一次设备的除尘、清理，扫净监控设备显露的尘土，对摄像机、防护罩等部件要卸下彻底吹风除尘，之后用无水酒精棉将各个镜头擦干净，调整清晰度，防止由于机器运转、静电等因素将尘土吸入监控设备机体内，确保机器正常运行。同时检查监控机房通风、散热、净尘、供电等设施。室外温度应在－20 ℃～＋60℃，相对湿度应在10％～100％；室内温度应控制在＋5℃～＋35℃，相对湿度应控制在10％～80％，留给机房监控设备一个良好的运行环境。
II. 根据监控系统各部份设备的使用说明，每月检测其各项技术参数及监控系统传输线路质量，处理故障隐患，协助监控主管设定使用级别等各种数据，确保各部份设备各项功能良好，能够正常运行。
III. 对容易老化的监控设备部件每月一次进行全面检查，一旦发现老化现象应及时更换、维修，如视频头等。
IV. 对易吸尘部份每季度定期清理一次，如监视器暴露在空气中，由于屏幕的静电作用，会有许多灰尘被吸附在监视器表面，影响画面的清晰度，要定期擦拭监视器，校对监视器的颜色及亮度。
V. 对长时间工作的监控设备每月定期维护一次，如硬盘录像机长时间工作会产生较多的热量，一旦其电风扇有故障，会影响排热，以免硬盘录像机工作不正常。
VI.对监控系统及设备的运行情况进行监控，分析运行情况，及时发现并排除故障。如：网络设备、服务器系统、监控终端及各种终端外设。桌面系统的运行检查，网络及桌面系统的病毒防御。
VII. 每月定期对监控系统和设备进行优化：合理安排监控中心的监控网络需求，如带宽、IP地址等限制。提供每月一次的监控系统网络性能检测，包括网络的连通性、稳定性及带宽的利用率等；实时检测所有可能影响监控网络设备的外来网络攻击，实时监控各服务器运行状态、流量及入侵监控等。对异常情况，进行核查，并进行相关的处理。根据用户需要进行监控网络的规划、优化；协助处理服务器软硬件故障及进行相关硬件软件的拆装等。
VIII. 提供每月一次的定期信息服务：每月第一个工作日，将上月抢修、维修、维护、保养记录表以电子文档的形式报送监控中心负责人。
监控系统维护协议
甲方：
乙方：
监控系统工程维护质保项目，经甲乙双方友好协商，特订立如下维护保修条款：
一、乙方的职责：
1、对甲方现有设备恢复正常使用。
2、对甲方的设备进行每月一次，每次两天的定期维护保养工作；
3、不论系统有无故障，每年提供12次定期维护保养服务，并提供相应的维护保养报告，年底提供 一份详细的年度维护保养报告，以供甲方对各系统设备运行状况有全面的了解，确保系统设施的正常运行。
4、在维护保养过程中如发现设备、零部件损坏，经甲方确认同意更换后，按原合同中规定的价格收费更换，如原合同中没有规定的设备及部件，按设备或零部件的成本价收费。
5、向甲方提供有关技术咨询服务。
6、如乙方没有按期进行维护保养工作，每少一次扣除维护费用的8%。
二、甲方的职责：
1、积极配合乙方进行系统维护保养工作。<br>
2、在系统出现问题后，应如实向乙方反映情况，提供维修条件。
3、及时支付维修保养费用。
三、合同金额及收费标准：
1、维修保养合同金额为：元人民币。
2、全年上门维护次数累计超过12次或全年维护保养工作累计超过48个工作日后，甲方需要乙方提供上门维护服务，服务费用按每人每天3000元计算，乙方在收到甲方预付款后派员到现场排除故障。
四、付款方式：
1、维护费按年度结算：合同签订后5日内支付年度维护费用的50％，满6个月后5日内支付50％余款；
2、更换设备材料、零部件所发生费用，在收到乙方提供的费用票据后5日内甲方一次付清；
3、逾期付款时按未付款金额的5%收取滞纳金，满一个月后仍未付清余款，乙方视同甲方不需要乙方继续提供维保服务，乙方停止提供维修保养服务。乙方停止提供维修保养服务后，甲方需要乙方提供上门维修保养服务，服务费用按每人每天3000元计算或一次性付清自停止之日起本合同约定的定期维护保养服务费。乙方在收到甲方付款后派员到现场排除故障。
五、违约责任：
1、本合同在执行过程中，任何一方违反合同条款，双方进行友好协商，协商不成按经济合同法有关条款处理。
六、其他：
1、本合同未尽事宜双方协商，另行签定补充协议；
2、本合同自双方签字盖章后生效；
3、本合同期限为 1 年；
4、本合同一式 二 份，甲方执 一 份，乙方执 一 份。
甲方： 乙方：
代表： 代表：
地址： 地址：
电话： 电话：
传真： 传真：
1、如何导出导入osdmap
1.1先停掉坏的osd,以及一个好的osd(因为ceph-objectstore-tool执行时需要停止osd),然后执行导出导入即可
命令例子：其中84是好的osd,85是有问题的osd
ceph-objectstore-tool --op get-osdmap --epoch 145039 --data-path /data1/ceph-osd/ --journal-path /var/log/ceph/ceph-84/journal --type filestore --file osdmap145039
ceph-objectstore-tool --op set-osdmap --epoch 145039 --data-path /data2/ceph-osd/ --journal-path /var/log/ceph/ceph-85/journal --type filestore --file osdmap145039
PS：其中145039为对应的版本号，data-path与journal-path填写自己osd对应的路径
2、找到正确的epoch版本
这个要通过报错的osd日志查看，在启动的时候，osd会加载一个epoch版本A，这个版本是它正在执行的，缺少的epoch版本在它之前。然后在 dump of recent events中发现已经执行的epoch版本B,以及ecoch版本C。将在max(B,C)到A之间的版本都导入一遍（也可以导入一个版本，启动一次观察，就是太麻烦了）。我日志中A=145068,B=145011，C=145012,所以我把145013到145067之间所有的ecoph版本都导入进去了，结果正常启动了。我的日志入下图
1、产生原因 ：
2个osd之间的osdmap版本如果相差过大(相差可能在50左右)，会导致2个osd通讯的时候报wrong node。如果偶尔出现一次wrong node，那么问题不大，因为osd某个操作卡主了，然后恢复获取了最新版本的osdmap。如果osd日志一直在报，说明有osd同步osdmap出现问题，会导致osd down掉，心跳超时（可能），甚至出现osd大量吃内存，导致服务器挂掉。日志如下：
2、查看osd的osdmap版本
通过命令查看：ceph daemon osd.xx status ——xx标记对应的osd编号
命令结果例子：
{
"cluster_fsid": "df181181-2154-4816-a2b7-d6eae79980fb",
"osd_fsid": "d5edacd3-cee7-45eb-90df-e381d8684dfb",
"whoami": 15,
"state": "active",
"oldest_map": 92570,
"newest_map": 158146,
"num_pgs": 2105
}
其中newest_map表示osd的最新版本号
3、查看集群的osdmap版本号
命令：ceph -s
这里：178170时最新版本号
4、确定osd版本是否有问题
多次间隔执行命令ceph daemon osd.xx status 查看osd版本号，正确状态如下：
4.1、查询出来的版本号一直保持跟集群版本号一致
4.2、小于集群版本号，但是在不停增大，最终会达到集群版本号
5、出现osd不更新osdmap解决办法
到目前为止，我没有找到osd不更新osdmap的根本原因，我使用过ceph daemon osd.xx dump_blocked_ops 查看是否有阻塞的操作并解决阻塞，但是依然不行，即使返回没有阻塞，还是不更新。可能可以让osd重新更新的方式：
1、将对应的osd out出集群（osd还是up的），过一阵观察一下版本号（我的就是这样回复的）
2、重启osd
1、问题日志
2、解决方式：
1、检查服务器时间是否一致
2、检查集群中的keyring与本地osd的keyring是否一致:
使用命令：
ceph auth list从mon中获取所有osd的keyring,
cat /var/lib/ceph/osd/ceph-xx/keyring获取本地osd的keyring
3、去掉验证 ，重启所有的mon、osd，修改ceph.conf中的如下参数为
auth_cluster_required = none
auth_service_required = none
auth_client_required = none
1、问题日志
2、解决方式
1、查看服务器时间与服务器网络（我的不是这个问题）
2、一般心跳超时是其他问题引起的，这里可以先调大心跳超时时间（我调大了心跳超时，解决了其他问题之后，就没有心跳超时了），修改配合文件ceph.conf的参数
mon_osd_report_timeout = 1800
filestore_op_thread_suicide_timeout = 1800
filestore_op_thread_timeout = 600
osd_heartbeat_grace = 600
osd_op_thread_suicide_timeout=1800
osd_op_thread_timeout=36000
这个配置可以先放到[global]，等解决了问题，在去掉，也可以根据实际情况，自己调整参数
1.查看日志查看osd卡在哪里
日志调整级别：修改配置文件ceph.conf参数，添加debug_osd=10（15/20），数值越高，打印越多。如果已经启动osd,想更改日志级别，可以通过命令：ceph tell osd.xx injectargs --debug-osd 5
2、根据日志信息解决问题
我是卡在了load_pgs上，因为整个集群状态不对，而pg数量又很多，加载很慢，这时候需要考虑服务器压力，可以一个一个慢慢启动，不要一下子启动完。
1、问题原因
incomplete状态表示：Peering过程中由于无法选出权威日志或者通过choos_acting选出的acting不足以完成数据恢复，（例如针对纠删码，存活的副本数小于k值）等，导致Peering无法正常完成。即pg元数据丢失，无法恢复pg状态
2、解决问题
1、使用ceph-objectstore-tool工具将incomplete状态的pg标记为complete
2、操作步骤：
操作前提：设置集群flag:noout nodown noup noin PS：这里的目的是为了不让pg分布变化，我因为osd都起来了，只设置了noout nodown
第一步：通过命令ceph pg dump_stuck |grepincomplete >incomplete.txt 从集群中导出incomplete状态的所有pg
第二步：通过第一步知道了pg所在的2个osd在哪里，stop这2个osd
第三步：对这2个osd上的pg通过命令做标记，命令如下
ceph-objectstore-tool --data-path /data4/ceph-osd/ --journal-path /var/log/ceph/ceph-15/journal --type filestore --pgid 9.ea8 --op mark-complete
ceph-objectstore-tool --data-path /data8/ceph-osd/ --journal-path /var/log/ceph/ceph-91/journal --type filestore --pgid 9.ea8 --op mark-complete
第四步：启动这2个osd(启动顺序没有关系)
第五步：观察集群中incomplete是否少了
第六步：重复第二步以及之后的操作，直到incomplete没有
3、特别说明
3.1、标记complete的过程，可能给导致集群degraded、misplaced增加，这是正常的
3.2、原因：因为我在标记的过程中，缺少了导入导出pg步骤。我这里没操作导入导出是因为pg数量有点多，而且pg比较大，导入导出会让2个osd停太久了，而且我觉得让集群自己恢复比较好
3.3、导入导出pg命令:
ceph-objectstore-tool --data-path /data3/ceph-osd/ --journal-path /var/log/ceph/ceph-2/journal --type filestore --pgid 4.15d5 --op export --file /data10/55/pg4.15d5
ceph-objectstore-tool --data-path /data8/ceph-osd/ --journal-path /var/log/ceph/ceph-5/journal --type filestore --pgid 4.15d5--op import --file /data10/55/pg4.15d5
选择一个osd为主，另一个为副，将一个导入到另外一个pg，导入导出需要停止osd。以上是将osd.2中的4.15d5导入到osd.5中
1、如果能重启对应pg的osd,那是最好的，问题自然解决
2、如果osd对应的数据盘损毁或者其他原因无法启动这个osd
第一步：将这个osd删除，命令
ceph osd crush reweight osd.xx 0
ceph osd out osd.xx
ceph osd crush remove osd.xx
ceph osd rm osd.xx
ceph auth del osd.xx
第二步：清理当前osd的硬盘或者新加一个硬盘
第三步：新启动一个编号相同的osd
第四部：重复上面的操作，处理掉所有有问题的osd，如果还有down，没事，等集群自己恢复处理（我就是启动了一个新的osd,有pg处理incomlepte+down，我标记完了incomlepte，down就自己消失了）
1、原因
这个状态的PG没有被 ceph-osd 更新，表明存储这个 PG 的所有节点可能都 down 了。拥有 PG 拷贝的 OSD 可能会全部失败，这种情况下，那一部分的对象存储不可用， monitor 也就不会收到那些 PG 的状态更新了，这些pg就被标记为stale
2、解决方法
第一种：osd down了之后能正常起来，那只要启动
第二种：
1.使用命令ceph pg dump |grep stale找出stale的pg
2.使用命令ceph pg force_create_pg $pg_id,这时pg状态变为creating
3.重启集群中所有的osd
3、特殊说明
我当时是第二种情况，然后我按上面的步骤操作了。结果所有的osd启动都卡主了。我猜测可能原因：当时我force_create_pg的数量有3000个，这个数量有点多，所以osd就大量卡住了，很久很久才能启动，可能有几个小时。所以这个操作要慎重，建议如下
1、这个stale的pg最后处理
2、一次不要force_create_pg太多，osd重启时，一个重启成功之后，在重启另一个
这个比较简单,直接执行命令：ceph pg repair $pg_id 修复
说明集群中osd有问题，需要解决osd问题，我就是有3个osd问题，我out了这3个osd，这2个状态就很快消失了
1、问题发现 ：ceph -s 或者mon进程死掉看到日志
2、产生原因
产生了大量的epoch，导致mon的store.db的数据极速膨胀。这个是我集群出现问题之后才出现的。我之前集群正常时没有这个现象。不知道等集群正常之后，会不会自己恢复正常。
3、解决方法
第一种：对数据进行压缩，使用命令 ceph tell mon.ceph163 compact (ceph163是我mon的名称) 。
第二种：使用ceph-mon -i HOST --compact进行压缩启动 ，这里的host我使用的是ceph163，主机名称
说明：不管使用哪一种，都要注意一点：操作压缩时，硬盘都会先扩大然后再缩小的，所以要留足空间。第二种的优势在于可以使修改ceph.conf中的参数mon_data=/data10/ceph153路径生效。我后来的mon数据太大了，我就更新路径到了数据盘：只要把对应的mon数据存数据mv到其他目录即可
第三种：等集群正常了，修改mon的配置参数试试（未验证，参数可以调小一些）
mon_min_osdmap_epochs=500
mon_max_pgmap_epochs=500
mon_max_mdsmap_epochs=500
4、特别注意：
默认当mon所在存储应硬盘剩余5%空闲时，mon进程会自杀。
将对应osd节点设置为out即可(osd进程依然存在)，它会自动移除数据并把对应数据盘的数据删除，等到数据移除完毕，正常关闭删除osd即可
命令：ceph osd out osd.xx
当需要迁移服务器，需要关闭集群时，先设置ceph osd set nodown ceph osd set noup ceph osd set noout ceph osd set nobackfill ceph osd set norecover 保持集群不变，然后关闭各个osd,关闭mon,关闭rgw。
ceph osd set norebalance
——禁止集群pg做从均衡，当出现问题时，可以设置，用于排查问题
ceph osd set nobackfill
——禁止修复数据 backfill，当出现问题时,我们暂时不想修复数据，可以使用，配合nobackfill 一起使用
ceph osd set norecover
——禁止修复数据 recover，当出现问题时,我们暂时不想修复数据，可以使用，配合nobackfill 一起使用
ceph osd set nodown
——当集群出现问题，osd一会儿up，一个down的时候，可以使用这个命令，禁止osd down
ceph osd set noup
——当集群出现问题，osd一会儿up，一个down的时候，可以使用这个命令，禁止osd up
ceph osd set noout
——禁止集群中的osd自动因为长时间down，而out
ceph osd set nodeeep-scrub
——不做深度处理取消使用对应的unset即可，比如ceph osd unset noout
ceph osd out osd.xx 设置单个osd的状态为out
ceph osd in osd.xx 设置单个osd的状态为in
ceph osd down osd.xx 设置单个osd的状态为down
ceph tell osd.xx injectargs --debug-osd 20 实时修改osd.xx的日志级别，不需要重启osd
ceph tell mon.xx injectargs --debug-mon 20 实时修改mon的日志级别，不需要重启mon
ceph tell osd.* injectargs --osd_recovery_sleep 1 单位秒，刚开始设置为1，怕服务器有压力，观察之后可以去掉设置为0
ceph tell osd.* injectargs --osd_max_backfills 1 调整恢复线程数，可以根据实际情况调整
ceph tell osd.* injectargs --osd_recovery_op_priority 60 调整恢复线程的级别
ceph daemon osd.xx status 查看osd.xx的状态，主要看osdmap版本号
ceph pg dump 查看所有的pg信息
ceph pg dump_stuck stale 查看pg状态为stale的数据
ceph pg dump_stuck inactive查看pg状态为inactive的数据
ceph pg dump_stuck unclean查看pg状态为unclean的数据
ceph -s 查看集群情况
ceph osd tree 查看osd状态树
ceph health detail 查看集群健康详情
ceph pg pg_id query 查看某个pg信息
ceph osd getmap -o osdmap.bin查看osdmap图
ceph-dencoder type OSDMap import osdmap_197 decode dump_json 将osdmap导出成json格式
机房环境对服务器的正常运转有着重要的影响作用。因此，服务器维护和保养的首要环节就是做好机房环境建设。机房要保证充足的空间，用以安装和配置服务器的相关设备，机房的隔断，地板等要做好防静电等细节处理。机房的防火工作也很关键，要做好墙面和电缆等的防火处理。一旦遇到火情等，如何保障设备的安全，如何保障人员的有序撤离等都是机房建设中需要考虑的因素。机房的温度和湿度也应当操持在一定的范围，温度和湿度对于电子产品的正常工作有着非常大的影响作用。服务器是电子设备中对温度和湿度都较为敏感的设备。如果服务器所在的机房太过于干燥，那么人员在机房中与设备接触的过程中非常容易产生静电。这种静电一般都有几千伏乃至上万伏，这对服务器的正常运行时非常危险的，极易引起严重的事故。如何科学合理的做好机房布局和管理工作是机房建设的关键。目前我国的计算机服务器机房管理还存在着很多需要完善的地方，比如机房的管理现代化水平还不高，很多监测和维护工作还单纯依靠人力完成，没有形成信息化和网络化的管理机制。其实，电子检测系统不管是在设计上还是在实施上并没有多少难度，但由于我们重视程度的不够，机房建设的总体水平依然在低位徘徊。
如需了解更多，请访问蛙云官网wwwwayuncn
专业领域十余载，倾情奉献
一次沟通，终生陪伴
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）