其实玩过的手机不少,blackberry,android,刷机都还是比较简单的事情
今天拿到一个canada rogers的n97 mini,折腾了一下午,简单记录下过程

初始状态,有网络锁,完全无中文支持

先去taobao了一个解锁码,80
一共只有三次输入机会,看来没有盲目尝试是正确的

接下来的调研过程比较痛苦,总结一下几个线路

先使用nss改code,一组数字代表了机器的基本型号和销售市场
初始的code无法自动安装中文系统(补充:可以通过Phoenix强刷中文模块解决)
改这个比较简单,挑了个hongkong的code,改上拉倒,也就没尝试强刷的方式

如果手机本身的rom比较旧,那么用nokia自己的nsu可以自动升级
可惜手上这个自己就很新,自动升级失败

接下来通过Phoenix下载rom,之前修改过code的话,会自己找到对应的中文rom
按提示下载到Phoenix的安装目录,product目录里会多出来一个rm-555的目录

由于北美和亚太对型号的定义有区别,需要把rm-555改成rm-553
然后打开Phoenix,firmware update,搞定

穷折腾啊穷折腾

之前配过几次,没什么感觉
今天有需要配置第二个slave,了解的更多了些,就随便写写

原始的两个节点,典型的master slave模式,第三台服务器到的时候,犹豫了一下是继续slave还是cluster
cluster的话,逻辑一体,配置可能复杂点,但使用起来简单,不过有听闻在规模不大的时候,cluster的性能及其一般
加上网络环境只是百兆互连,想想还是没上cluster

第二个slave的添加,并不是与第一个slave一样直接挂在master上
实际上是个链型结构,原来的第一个slave也启动log-bin,第二个slave使用第一个slave作为自己的master

负载均衡方面,最土的办法是在程序上读写分离,并将读操作按一定模式分布的两个slave上
或者就是使用mysql-proxy之类的分发器,这个方法也不是很好,它并没有办法维护php到mysql的连接状态
会导致一些依赖连接的指令失败,诸如set names gbk,跟在它后面的select指令很有可能会被分发到其他节点上
类似的还有auto_increasement和select last_insert_id()等等

安装环境就不说了,碰到个及其sb的bug

安装莫名失败,错误代码0×80070643,source: contacts

系统日志里有某kb安装失败的提示

折腾了两个钟头,原因竟然是我禁用了windows firewall

靠靠靠

debian5 lenny

默认安装的php,今天装上zend optimizer需要跑些加密程序

挂上zendoptimizer以后,php就不停的segmentation fault

zendoptimizer和php-apc冲突,卸了后者就可以了

php-apc – APC (Alternative PHP Cache) module for PHP 5

关于硬盘

目前碰到的情况,当一台机器上既有自己的硬盘,又有外挂阵列,甚至usb存储设备
会出现每次启动sd[a b c d e...]对应设备不同的情况,一旦出现,fstab里的挂载信息就不对了
至于grub里的hd(x,x)和root参数,似乎没什么影响
解决的办法,系统正常启动后,把fstab里的挂载信息改成by-uuid的设备地址
每块硬盘设备在/dev/disk/by-uuid/里都会有对应的设备,无论sd怎么变,这个不变的

关于网卡

既有板载网卡,又有外插网卡,理论上modprobe.conf里做好alias就可以指定设备
有些特殊情况,比如板载和外插用的是一个驱动,指定编号就挺困难
最近又碰到个特例,机器安装完系统后,更换了同一型号的网卡,会导致设备dev消失的情况
这些,都可以通过修改/etc/udev/rules.d/*-persistent-net.rules来搞定
说到这,上面sd顺序混乱的问题,也可以通过修改*–persistent-storage.rules来定死,避免kernel根据设备发现的顺序分配设备号

由于一个项目,最近折腾这个东西不少时间

一套6节点的10G集群,一套16节点的IB集群,两个NAS节点

不庞大但相当全面的集群……

虽然标题说ROCKS,不过这玩意儿也没什么好说的,自动化安装管理集群里的操作系统
还是我不太熟悉的RH,不过也是没办法的事情,这些高级的通信设备,多半都只有rh或suse有驱动

具体做的事情跟机器人一样,安装OFED,调试IB网络,ipoib,RDMA,诸如此类
目前的水平也仅限于调试通而已,性能问题就再说吧…

为什么还在用NAS,nfs真不好玩,硬要说的话,通过IB的NAS,可以提供40Gb的带宽
SAN的通道也不过4G8G,不过,得什么样的磁盘设备才能提供这样的性能啊…

西厢

玩意儿出来一段时间了,理论上,以它提供的功能,应该立刻火遍大江南北才对
它一直不火,也一直让我没什么尝试的动力
事实说明,无聊是一切成果的最终动力之一

原理什么的就不说了,懂行的自己去看看,也就知道了,不懂得解释也没用
由于最早的实现是在linux的netfilter上,也难怪老百姓没让它迅速的火起来
安装十分简单

第一次安装,没有实质效果,查了查,linux的NAT会直接丢弃用于迷惑GFW的包

第二次直接装到网关上,就成事了,NAT后面的客户端要怎么用,有人说要放到网关的FORWARD链上
我没有成功,也没有继续尝试,曲线一点,网关上直接装了个http proxy,也就可以了

有一些不便,西厢的设置上,需要指定访问哪些地址范围的时候,才启用功能
要手动收集twitter之类的地址范围还是挺麻烦,不过估计稍微等等,就会有人做好现成的配置包

到了这个层面上,不免要操心GFW多久会把这个漏洞堵上
原理上说,GFW为了高效对TCP连接状态的监控很有限
这几乎是个原则性的问题
直接修改策略监控所有包,成本太大,估计短期实现困难
实现一个改进些的tcp栈,运算量的成本也会增大不少,至少一个数量级,也就更容易被syn flood搞瘫痪
比较可行的,我就不去想什么可行的了
至少,这是个开头,在GFW实现完整的TCP栈之前,就是个来回斗法的过程

比较担心的,把上面搞急了,直接封禁IP,那样,我们离lan就更近了

rocks

今天第一次实际接触了rocks的安装
说的简单些,就是rh系列的linux捆绑了一些自动安装的套件和开发环境
提供一个快捷部署集群计算环境的方式

说是挺自动化,却也因为包装的太复杂,出了问题不好排查
全自动情况下,对各个节点硬盘网络环境有着相当的一致性要求

今天就碰到这样的情况,通过千兆口PXE启动,启动后,内核识别到了另外的万兆网卡
启动时的千兆卡就变成了eth2,导致了kickstart不能正常启动
理论上,编辑中间过程的一些配置文件可以解决问题,
为了求效率,就把万兆卡拔了再安装

内置了不少集群适应的功能,诸如多台机器同时运行同一命令,查询节点状态,任务分配等等
细节上,看来还是需要一段时间熟悉

话说,集群内部的通讯,放着好好的IB不用,上什么万兆,╮(╯▽╰)╭

On January 12, we announced on this blog that Google and more than twenty other U.S. companies had been the victims of a sophisticated cyber attack originating from China, and that during our investigation into these attacks we had uncovered evidence to suggest that the Gmail accounts of dozens of human rights activists connected with China were being routinely accessed by third parties, most likely via phishing scams or malware placed on their computers. We also made clear that these attacks and the surveillance they uncovered—combined with attempts over the last year to further limit free speech on the web in China including the persistent blocking of websites such as Facebook, Twitter, YouTube, Google Docs and Blogger—had led us to conclude that we could no longer continue censoring our results on Google.cn.

So earlier today we stopped censoring our search services—Google Search, Google News, and Google Images—on Google.cn. Users visiting Google.cn are now being redirected to Google.com.hk, where we are offering uncensored search in simplified Chinese, specifically designed for users in mainland China and delivered via our servers in Hong Kong. Users in Hong Kong will continue to receive their existing uncensored, traditional Chinese service, also from Google.com.hk. Due to the increased load on our Hong Kong servers and the complicated nature of these changes, users may see some slowdown in service or find some products temporarily inaccessible as we switch everything over.

Figuring out how to make good on our promise to stop censoring search on Google.cn has been hard. We want as many people in the world as possible to have access to our services, including users in mainland China, yet the Chinese government has been crystal clear throughout our discussions that self-censorship is a non-negotiable legal requirement. We believe this new approach of providing uncensored search in simplified Chinese from Google.com.hk is a sensible solution to the challenges we’ve faced—it’s entirely legal and will meaningfully increase access to information for people in China. We very much hope that the Chinese government respects our decision, though we are well aware that it could at any time block access to our services. We will therefore be carefully monitoring access issues, and have created this new web page, which we will update regularly each day, so that everyone can see which Google services are available in China.

In terms of Google’s wider business operations, we intend to continue R&D work in China and also to maintain a sales presence there, though the size of the sales team will obviously be partially dependent on the ability of mainland Chinese users to access Google.com.hk. Finally, we would like to make clear that all these decisions have been driven and implemented by our executives in the United States, and that none of our employees in China can, or should, be held responsible for them. Despite all the uncertainty and difficulties they have faced since we made our announcement in January, they have continued to focus on serving our Chinese users and customers. We are immensely proud of them.

这是些被炒的很热,多数情况下被拿出来唬人的技术名词。

虚拟化还是挺好理解的,无非是隔离了硬件与操作系统持续了数十年的直接联系。与集群技术一起,建立了软件硬件之间相互的1对n的关系。
只不过集群还发展在应用层面,对多套硬件的使用限制很多。

云是什么?当看到国内某杀毒软件打出云杀毒的概念时, 我是彻底无语了。狭隘的定义,云就是硬件和虚拟化平台的结合体。
先进在哪里?最初的标榜的优势,充分利用硬件资源,不用再为隔离应用而分别购置硬件。对于国人来说,这个优势不明显,
或者说不够充分。
先来说说需求,为什么要隔离应用。在设计大型系统时,要将功能模块话,同时将基础性的模块标示出来 。
为了提供系统稳定性,那么对基础性模块的保护就十分必要。除此之外,也不希望看到一个功能模块出问题,导致整个系统崩溃。
最坏的情况,如果有模块出现问题,能够快速恢复。

当一个系统庞大到你不可能关注每个细节的时候,满足上面的系统要求就十分关键,试想一个蹩脚程序员的一行代码,存在拖垮整个
系统的可能性,每个系统管理员心存这样的担忧已经很久很久。

云的出现,硬件资源就不再是一台一台的服务器,而是一个整体的计算能力资源,对硬件的需要,也不再是以机器为单位,
而是从云中分割出的计算能力资源。云本身对硬件资源的整合是松散而耦合的。在完美隔离应用的同时,省略了硬件配置和系统安装配置两个需要在现场的过程
最坏的情况,假如有模块受到攻击,系统被污染,在排查模块本身漏洞的同时,部署一个全新的应用环境只是几分钟的事情。
这还不够吗,全新的虚拟化技术允许动态的迁移过程。诸如有硬件提示错误了,添加新的服务器可以分担负载了等等这些情况,
可以在应用不停的情况下直接进行。

说了这么多好处,也要说说缺点。自身对计算资源的损耗,这是无可避免的。各种虚拟化技术的特点也会在这方面体现出来
诸如半虚拟化的xen和openvz性能就要优于全虚拟化的vmware和kvm,但全虚拟化保留了宿主环境的纯洁性,这也是个优点。

从云中分割出的计算资源,最大的单体也会小于云中最强主机的计算能力,如前面所说,整合硬件资源给一个应用,这是集群该干的事情。

由此诞生的框架,由云负责整合管理硬件资源,提供计算能力,对需要超量计算能力的应用,再通过单独的应用集群技术,整合云的计算资源。
有点浪费,但很灵活,也很省事。

下面来几个名词解释:

私有云     云,自己造,自己用的

公共云     诸如amazon的EC2,由企业提供,使用者租用

混杂云     跟上面不同概念的分类,指的是云中存在不同的虚拟化技术,甚至有纯粹硬件主机直接服务的存在

« Older entries