Tags
- Airchina
- Android
- Anti-Spam
- Bluetooth
- bugs
- ChinaSouthern
- Django
- DNS
- Enterprise
- fastcgi
- Hainanair
- HAM
- HongKong
- InnoDB
- IPTV
- iSCSI
- kubernetes
- large-scale
- lighty
- Linux
- Logging
- Macao
- Meituan
- MM
- MySQL
- nginx
- Oracle
- Outdoor
- Percona
- Photo
- postfix
- Python
- RedHat
- Sentry
- systemd
- Traffic
- Travel
- Virtualization
- xtrabackup
- 信用卡
- 奥运
- 美食
- 规范化
- 软件工程
Meta
Blogroll
Mine
Category Archives: 默认分类
从神州租车更改手机号，看数据库关系设计
我搬来深圳之后，就换了手机号。为了应对一些出行需求，我就打算从神州租车租辆车来用。用新手机号注册之后提交身份证，结果提示该身份证已经被占用。联系客服，说是一个135的北京手机号占住了，还提示我以前在嘉峪关租过车，客服可以帮忙把这个135的登录手机号改成我的新手机号。我检查了一下通讯录，认识，跟他打了招呼之后就同意了客服的做法。 但其实，这个事情暴露了神州租车方面的数据库强关系设计，与实际业务冲突的问题。我和这位朋友之前两次一起租车，因为他当时还不会开车，所以登记了我的证件，但后续他仍有使用此注册名租车的业务需求啊。身份信息应该关联在“一次租车行为”而不是关联在“一个注册用户”身上，也就是每次发生租车行为的时候，把身份信息从注册信息复制过来，或者由门店人工录入身份信息到“一次租车行为”的数据库记录里。 这不是关系范式之间来回迁移，而是正确与错误的区别。 联想到以前在美团我们自制的一个用作软件版本发布的小系统，旧的设计并没有把“发布功能相关设置”关联到“一次发布行为”，而是关联到“要发布的应用”，以至于检查每一次发布行为到底为啥不正确的时候，根本不敢确定设置页面里看到的设置就是当时生效的设置。 这个错误在后面重构中被推翻了。
配置管理 vs provisioning 及配置管理工具的几点随想
关于“怎么构建一个确定的运行环境”这件事，有多个流派，其中一个是配置管理，另一个是provision流。 配置管理流派，适合于物理服务器、虚拟机等等，有机会长期存活的环境。因为它们有机会长期存活，在其生命周期里需要使用技术手段去维持一个有序可控的状态，排除软件运行时累计的旧日志和临时数据、手工操作带来的计划外变更等等影响。 而provision流派，直接从模版构建一个（容器或虚拟机）实例起来运行，用完就扔，基本上没有重新调整的价值。这种东西往往依赖于服务注册与发现机制，因为在它真正起来运行之前，网络通信方面的参数无法被外界预知，外界不知道如何跟它通信；对于日志和数据，也提倡使用显式远程的方式去访问。 再说说配置管理工具的几点随想： 我最近一年在给下属的一个公司做一些产品运维工作，其中遇到把设备投放到客户的网络环境去运行这种情况。考虑到网络通信的问题，我只好选择了“反向连接”的saltstack软件。在通信的角度来考虑，配置管理工具可以分为：master主动连接minion（ansible等）、minion主动连接master（puppet、saltstack等） 今天听师兄说他的一个同事因为认知问题，把一批机器glibc给删掉了。尝试恢复的时候，他发现ansible无法正常运行（我猜想sshd启动python的时候因为缺glibc而失败了），只好改用saltstack。因为saltstack的salt-minion是长期运行的，一旦启动之后，外部依赖较少，才能在glibc被删除这么极端的条件下苟活。在“有没有agent”的角度考虑，配置管理工具可以分为：有agent（saltstack、puppet、cfengine等）和无agent（ansible等） 另外，其实还有一个分类角度，就是主动和被动。saltstack和ansible是主动式的，运维工程师可有更多的主动权，可以用手工指定minion，或者指定批次规模分批执行等手段，控制变更的节奏；cfengine、puppet等是agent定时刷新式的（虽然听说也可以主动？不过我经验较少还没用过），得按定时器来，这种情况下就得运维工程师多看监控了，一不小心，死都不知道怎么死的。
在嵌入式开发板上使用蓝牙耳机
简单记录一下： 安装 bluez pulseaudio-module-bluetooth 软件包 pulseaudio是用户级后台服务，视情况可能需要手工-D启动之 bluetoothctl命令进入交互式界面，先scan on 等看到蓝牙耳机之后，pair和connect到蓝牙耳机的MAC地址，看到连接成功之后scan off并退出bluetoothctl pactl list sinks查看设备，看看它支持哪些profile，有可能需要通过pactl set-card-profile将其切换到a2dp aplay -Dpulse 指定pulse虚拟设备播放文件 还没搞定录音。看起来话务耳机在handfree等模式似乎需要特殊步骤激活录音模式？
hostname和dnsdomainname命令
先讲结论： 忽略已经过时的NIS/YP相关内容（/sbin/sysctl kernel.domainname、/bin/domainname、/bin/nisdomainname、/bin/ypdomainname等） /bin/hostname、/sbin/sysctl kernel.hostname 和 /bin/uname -n 是一码事，都是本机的主机名 /bin/dnsdomainname 命令会把上述主机名按“第一个点”分成两端，输出后一段。这是简单的字符串处理的结果，在内核和DNS层面均无正式意义。 /etc/resolv.conf文件里的search或domain指令，用于从本机访问外部短主机名时，补充域名的后缀部分。 hostname命令： 通过gethostname(2)函数读到本机的主机名。在glibc的情况下，gethostname(2)不是syscall而是标准库函数，转而调用uname(2) （我不太确认调用的是glibc uname还是syscall uname）。根据 https://github.com/torvalds/linux/blob/master/Documentation/sysctl/kernel.txt#L285 的说法，/proc/sys/kernel/hostname、sysctl hostname 和hostname命令应该是功能相同的。 hostname -d 或者 dnsdomainname 命令： 根据/etc/host.conf指定的顺序，先尝试/etc/hosts然后尝试DNS，查找自己的主机名。如果能找到，把第一段去掉之后，输出剩下的部分。这个输出不具备内核意义，只是主机名经过字符串处理之后的派生结果 hostname –fqdn命令： getaddrinfo()函数查询到的ai_canonname strace观察到的行为是去DNS查一下主机名（如果主机名是短形式，按需补充/etc/resolv.conf里声明的search/domain后缀）对应的A记录，只要能查到，即使返回的IP地址不是本机的也不管，就以这个主机名作为结果。 hostname –all-fqdn命令： 拿自己的IP地址们循环调用getnameinfo()函数（strace/tcpdump观察到的具体行为是去DNS查PTR记录），并全部输出
为什么有些系统是动作式的而非描述式的？
接手一个旧系统，上线发布是“拷贝文件过去，替换掉，重启服务”这样的，而不是“把编译好的东西打包，发上去安装，包的scripts部分带有重启动作”。 是否打包、包里包含什么，很有讲究： 查询当前版本号：XXX -v vs rpm -qi XXX 重启服务：killall XXX && sleep 30 && XXX vs /sbin/service XXX restart 删除软件：rm -fr XXX vs rpm -e XXX 安装依赖： ldd XXX |xargs -n1 yum provides |xargs yum -y install vs rpm -i XXX … Continue reading
placeholder 2016年10月欧洲之行
6月办签证，因为英国当时在闹脱欧，签证审批速度大大降低，耽误了办理申根，连瑞航机票都耽误了。所以决定10月辞职后再去。 临辞职，拿了在职证明去办法国申根，但忘记提前买好英法之间欧洲之星国际列车的票，后来多花了好多钱 走之前没查时区，10天行程调了5次时区，痛不欲生 不喜欢法国的繁复建筑物，但很爱她的博物馆们；塞纳河左岸下午照不到太阳，是酸臭文人吹捧起来的地方。 英国很有沉淀感 国际标准时间曾经是巴黎天文台，但英国人解决精度问题之后，标准时间变成了“比我巴黎时间晚9分9秒的‘那个时间’”
django database router是个好东西
今天给sentry加了MySQL读写分离机制，记录一下： DATABASES里，（sentry的脾气比较怪）保留名为default的配置，写master数据库的参数；新增一个名为slave的配置，使用只读用户名密码，或开启服务器端read only 然后增加一个类，带四个函数： class DatabaseRWSplitRouter(object): def db_for_read(self, model, **hints): return ‘slave’ def db_for_write(self, model, **hints): return ‘default’ def allow_relation(self, model1, model2, **hints): return True def allow_migrate(self, db, app_label, model_name=None, **hints): if db == ‘slave’: return None else: return True … Continue reading
内训教程释出：from CGI to WSGI
古代时，读过MSDN里的《from C++ to COM》受益匪浅。后来学习Python，自己也写了一篇 from CGI to WSGI 的教程，用于内部培训。 https://julyclyde.org/pyCGIWSGI.pdf
给rq添加了RedisCluster支持
最近一直在和前同事Puff潘、RainSun吕合作，做一些给使用redis的软件增加redis cluster或者redis sentinel支持功能的工作。 传统上，做sharding工作有三种做法： 客户端支持，比如redis cluster客户端需要支持KeySlot计算（我报告的bug: https://github.com/Grokzen/redis-py-cluster/issues/153） 代理层支持：twemproxy、codis等 服务器端支持：比如MySQL partition table之类 我比较推崇的是第二种，但redis的cluster和sentinel都属于第一种，客户端需要有明确的能力和知识去处理连接多个服务器的问题，而这方面，各常见客户端库做的并不好。另外还有个问题是用Python语言写的各应用软件，往往直接写死了用redis库，而不是用rediscluster库或者运行期动态决定，导致根本不具备使用cluster的能力。 近期在看rq的时候，发现rq支持custom worker class，于是我就改了改，让它也支持custom connection class，并说服了作者merge进来。 https://github.com/nvie/rq/pull/741 不过其实我觉得还是略别扭。主要是因为生成connection对象的时候套了两层函数，为了补全function signature，并尽量减少其它代码的修改，不得不在两层都使用参数默认值，显得多余。尽管如此，还是很为自己能为基础软件做出贡献而感到高兴的。
Posted in 默认分类
Leave a comment
kube-proxy –proxy-mode=iptables 与 rp_filter 冲突
2015年12月16日，朱鹏安装了新版kubernetes master版本（比1.1新，为1.2alpha**），然后发现，访问 clusterIP:clusterPort 会发生无法连接的故障。 从集群内Node上访问 分别在Node rz-ep19和container里执行curl访问，发现container里curl可以成功访问，但Node上一般不行（偶尔成功，几率很低）。查看iptables规则，发现新版kube-proxy已经不再将请求REDIRECT到本机kube-proxy端口，而是： 先把PREROUTING、OUTPUT无条件指向KUBE-SERVICES链；如匹配不上KUBE-SERVICES链，则再尝试匹配发给docker0 在KUBE-SERVICES链里匹配clusterIP:clusterPort条件，然后发到KUBE-SVC-***链 在KUBE-SVC-***链中，用-m statistic –mode random –probability这样的条件将流量按等比例分给多个KUBE-SEP-***链 然后再在KUBE-SEP-***链中，将数据包DNAT给endpoint 为了减少干扰，我们缩减了kube-system/elasticsearch-logging 10.16.59.73:9200服务的规模，到只有一个endpoint 172.16.86.48:9200运行在rz-ep10上；rz-ep19 10.16.49.16作为运行curl的客户端 在rz-ep19的flannel接口上抓包，抓到了 10.16.49.16->172.17.86.48的TCP SYN，但没有收到回应。 在rz-ep10（endpoint Pod所在的Node）的flannel接口上抓包，抓到了和上述相同的包，也没有收到回应。 在rz-ep10的docker0接口上抓包，没有抓到 由此判断，rz-ep10的内核在转发时主动丢弃掉了 10.16.49.16->172.17.86.48的SYN，以至于无法建立TCP连接。查看/proc/sys/net/ipv4/conf/{all,flannel.7890}/rp_filter，发现flannel.7890/rp_filter内容为1，即在此网卡上执行“根据回溯路由检查数据包是否为伪造”的检查。因为源IP 10.16.49.16在rz-ep10看来理应出现自eth0而非flannel.7890接口，所以被判定为假造包，丢弃。 将此参数改为0，再去docker0上抓包，可以收到172.17.86.48发回10.16.49.16 SYNACK包；但rz-ep19上curl仍显示无法建立连接。 在rz-ep10的角度考虑，这个172.17.86.48->10.16.49.16的包应该从eth0发出，也就是在rz-ep19的eth0上收到。而在rz-ep19的角度考虑，源IP 172.16.86.48不应来自eth0，也会被rp_filter参数影响，丢弃掉，所以无法建立连接。把rz-ep19的eth0/rp_filter参数改为0，终于可以正常访问了。 从集群外访问 从办公区我的笔记本电脑 172.30.26.169 访问 10.16.59.67:80 服务，该虚IP被手工绑在rz-ep01上，ping可以通，但访问不通。 … Continue reading