Why Bootdev — Dynamic CDN

In the old days, we put images, css / js, woff etc any assets to CDN, so that clients can download somewhere that geographically optimised.

Around end of 2012 – early 2013, new idea comes out like we should CDN everything, so that we can reduce the complex architecture with memcache, page cache cluster (Varnish) or even microccache etc. Just 1 layer cache and having everything to CDN. Like architecture below.

dnamic cdn

Your website domain name will directly point to CDN with CNAME. And then the CDN will point to your load balancer address or your web server. So it is like a proxy. When you do create, it will 100% bypass CDN and goes to web server, when u do UPDATE, the CDN will update from web server then invalidate itself, when you do DELETE, the CDN will bypass request to web server and invalidate its cache. When you read, it read from the CDN, not from web server. So the CRUD action can be completed.

You will need your own cache invalidation strategy, like send update to cloudfront / using versioning object or url.

Here is a sample conf of how we bypass some URLs to go to web server, and making Drupal works.

E1EB6A9C-17EC-446D-AD59-80B471A4F962 62367506-DDC3-4E5C-8F05-24E2D20DBBBB

With AWS cloudfront, you can bypass header ORIGIN, so that you can preform CORs actions. Also you can use similar header bypass feature to detect mobile/PC. With such architecture well setup, theoretically, you can have unlimited PV, as your server wont be really hitted. Your bound will be write DB bound only, which is not a concern in most case.

If you don’t want to understand all these, but want to lower your cost and have higher traffic and faster response, contact bootdev at founders@bootdev.com ! We can deploy Dynamic CDN to you in minutes no matter you are using AWS or not. We can point our CloudFront account to your server, it can be Azure, Linode, or any bare-meter. It just need to be Drupal, and you can enjoy the best performance ever.

ref: https://media.amazonwebservices.com/blog/cloudfront_dynamic_web_sites_full_1.jpg

Advertisements

why BootDev — AWS management (EC2 decrease performance by time)

In our experience, if your EC2 got resource left for a period of time, lets say 1-2 months, even AWS say it is not, but we always experience performance drop. For example: server response time drop from 400ms to 600ms . Or CPU raised from 40% to 70% in average.

In many case, many users will not 100% * 24 * 7  consume their server resources. So, in my experience, AWS want to reduce cost and reallocate some resource privately to other clients. If your server is actually low utilization, it is OK. But, in my situation, we need high response time and we reserve the CPU for that. We will feel performance drop.

How we deal with that ? That is what auto-scaling group should do. If in your auto-scaling group, your server will keep renew itself. Like turning off old servers and start new servers, the EC2 resource allocation will maintain at best performance.

Such issue especially obvious in Drupal. Drupal PHP request involve in many hooks / functions / third party calls etc. Server CPU requirement is higher than other web PHP applications. So, renewing server can help to keep better performance.

How to deploy auto-scaling group ? Call BootDev 🙂

Hope above information can help anyone that feel AWS sometimes drop performance by time 🙂

 

 

 

 

淺談叢集式電腦 ( Clustering )

當你開始接觸 clustering 時就會發覺, 原來沒學 clustering 根本等於沒有學 Unix / Linux. 
我們一般情況用到的 SERVER / Client 只是皮毛. Clustering 一個字, 內裹包含了多種技術, 
以下例子是常用的
  1. HPC – High performance computing
  2. Server Load balancing 負載平衡
    1. DNS round robin
    2. LVS – ipvsadm
  3. HA – High availability
    1. XEN cluster
    2. Heartbeat
    3. DRBD - http://www.drbd.org/
  4. Parallel computing
    1. http://en.wikipedia.org/wiki/MPICH

今天所談的是入門級的 clustering, LVS

LVS – Linux virtual server主要是用作負載平衡 與 HA,

What is the Linux Virtual Server?

The Linux Virtual Server is a highly scalable and highly available server built on a cluster of real servers, with the load balancer running on the Linux operating system. The architecture of the server cluster is fully transparent to end users, and the users interact as if it were a single high-performance virtual server.

SOURCE: http://www.linuxvirtualserver.org/ 

負載平衡的意思是把一部服務器的工作分到多部服務器之上. 由一個服務器為主人 ( Master ), 其他為幫手 ( node ). 如下圖

more_on_clustering

更可以制定負載平衡的策略

詳程參考, http://linux.die.net/man/8/ipvsadm

    1. rr – Robin Robin: distributes jobs equally amongst the available real servers.
    2. wrr – Weighted Round Robin: assigns jobs to real servers proportionally to there real servers’ weight. Servers with higher weights receive new jobs first and get more jobs than servers with lower weights. Servers with equal weights get an equal distribution of new jobs.
    3. lc – Least-Connection: assigns more jobs to real servers with fewer active jobs.
    4. wlc – Weighted Least-Connection: assigns more jobs to servers with fewer jobs and relative to the real servers’ weight (Ci/Wi). This is the default.
    5. lblc – Locality-Based Least-Connection: assigns jobs destined for the same IP address to the same server if the server is not overloaded and available; otherwise assign jobs to servers with fewer jobs, and keep it for future assignment.
    6. lblcr – Locality-Based Least-Connection with Replication: assigns jobs destined for the same IP address to the least-connection node in the server set for the IP address. If all the node in the server set are over loaded, it picks up a node with fewer jobs in the cluster and adds it in the sever set for the target. If the server set has not been modified for the specified time, the most loaded node is removed from the server set, in order to avoid high degree of replication.
    7. dh – Destination Hashing: assigns jobs to servers through looking up a statically assigned hash table by their destination IP addresses.
    8. sh – Source Hashing: assigns jobs to servers through looking up a statically assigned hash table by their source IP addresses.
    9. sed – Shortest Expected Delay: assigns an incoming job to the server with the shortest expected delay. The expected delay that the job will experience is (Ci + 1) / Ui if sent to the ith server, in which Ci is the number of jobs on the the ith server and Ui is the fixed service rate (weight) of the ith server.
    10. nq – Never Queue: assigns an incoming job to an idle server if there is, instead of waiting for a fast one; if all the servers are busy, it adopts the Shortest Expected Delay policy to assign the job.

source: Man page of ipvsadm

負載平衡方法大致上有

  1. NAT (Network address translation)
  2. DR – direct routing
  3. Tunneling

以下是 LVS – NAT LOAD BALANCING 的參考

原意圖

VS-NAT

VS via NAT, source: http://www.linuxvirtualserver.org/VS-NAT.html

指令

Master (NAT)

echo 1 > /proc/sys/net/ipv4/ip_forward

ipvsadm -A -t 192.168.7.200:80 -s rr

ipvsadm -a -t 192.168.7.200:80 -r 192.168.7.201:80 -m

ipvsadm -a -t 192.168.7.200:80 -r 192.168.7.202:80 -m

ipvsadm -a -t 192.168.7.200:80 -r 192.168.7.203:80 -m

ipvsadm -L –stats (現時的連接情況)

Nodes:

Set default route to 192.168.7.200

route add default gw 192.168.7.000

ip 地址

名稱 意思
192.168.7.200 Master
192.168.7.201 Node
192.168.7.202 Node
192.168.7.203 Node
192.168.7.1 Default GW
80 Www – web 服務器的 port number
rr Round robin 策略
-m LVS NAT
-a ADD SERVER
-A ADD SERVICE

Thanks, 有興趣多討論請跟我連絡 keithyau@yubis.net !!

how to maintain a SME class network如何維護一個中小企的網絡 – Availability

如何維護一個中小企的網絡

系統管理是一門很高深的學問. 大企業一般把範圍分成 可靠性, 準確性, 安全性, 靈活性.言而, 滿足所有要求是極之昂貴的. 因此, 中小企要因應自己的情況作資源控制. 例如銀行需要可靠,準確,安全. 但大型伺服器的靈活性較低. 設計公司則需要靈活可靠. 以下是一般情況下注重的 IT risk 4A 例子.

在未來數篇文章, 我將會續一講解 IT 風險管理 – IT risk 4A, Availability, Accuracy, Access, Agility.

    1. Availability 可靠性

      1. Server availability 伺服器可靠性

      2. Database availability 資料庫可靠性

      3. Support team availability 支援人員可靠性

      4. Backup 備份

      5. Crisis response time 危急救援反應

      6. Monitor system 監察系統

      7. Redundancy 後備

    2. Accuracy 準確性

      1. Information accuracy 資訊準確性

      2. Non-system source accuracy 來源準確性
      3. Control accuracy 管理準確性
    3. Access 安全性

      1. Firewall 防火牆

      2. User access control 權限管理

      3. Data deletion 資料移除

      4. Anti-virus 防毒

      5. Wireless lan security 無線網絡安全

      6. phishing 網路釣魚

    4. Agility 靈活性

      1. Infrastructure design 系統設計

      2. Virtualization 虛擬化

      3. Server independent software 跨平台軟件

      4. Modulization 模組化

      5. Reusable resource 可再用資源

  1. IT 風險管理 IT risk 4A

Availability 可靠性

      1. Server availability 伺服器可靠性

        伺服器可靠性就是說你的伺服器隨時隨地都可以應付使用者. 沒有當機, 斷電, 斷線, 重啟等情況. 一般的家庭電腦加上 Linux 系統, 已經可以做出99% 的可靠性. 但別以為這樣的可靠性很高. 99% 就是說, 約一百次服務中, 伺服器就會出現一次錯誤. 如果你的公司是跟錢銀上有很大關係的. 例如股票行, 就需要99.999% 的可靠性吧.

        硬件與系統 operating system 成為可靠性的主要關鍵. 當然好的技術人員亦很重要. 現時,可靠性極高的系統有銀行使用的AS/400 iSeries, IBM AIX, Solaris SPARC.

        那中小企怎樣 ? 除了以上的天價產品, 對中小企有以下建議
        1) Solaris 安裝在小型伺服器上. 可靠性有 99.9% 特性: 最適合java 環境
        2) BSD 安裝在小型伺服器上 可靠性有 99.9%, 特性: 特點是系統安全高, 而且快
        3) Linux 安裝在小型伺服器上 可靠性有 99%, 特性: 開源軟件最多, 硬件支援最好

        伺服器可靠性為最重要之基礎, 一切服務, 軟件, 技術都基於選用之伺服器建立.在選擇之前要多加小心. 這一步決定了以後公司在 IT 上投放的資源與人才陪訓的方向.

      2. Database availability 資料庫可靠性

        資料庫就像伺服器的銀行, 所有資料都放在裹面. 資料庫有很多類

        1) LDAP 建立的網絡資料庫作用是在伺服器中分享登入資料. 當有多個伺服器時, LDAP 就有很大的幫助.
        2) 一般以 SQL 語言建成的資料庫, 作用是存儲 / 取出大量資料. 如網站服務.
        3) XML 資料庫, 用作一些小型的資料存儲, 如伺服器設定

        一般而言, 中小企都會需要 SQL 資料庫, 跟一些軟件一起使用. ERP – entreprise relationship management, CRM – customer relationship management.

        選用資料庫時, 可靠性成為最重要的條件, 可靠性建基於資料庫可同時應付的要求之數量. 你可以想像成同一秒內資料庫可接受多少個要求– request.

        市面的注名的資料庫有 MySQL, PostqreSQL, Oracle 11g, Oracle 10g Express, IBM DB2. Oracle 11g IBM DB2 是一些企業級的資料庫, 收費都是企業級的. 可以同時間應付過千的要求 – request.支援的功能都較多. 例如

        MySQL 5是現在最流行的資料庫, 在大部份的伺服器都可以運行. freebsd, linux, solaris, windows. 同一時間可應付的要求約50 . 資料庫存取速度很不錯. 大部份資料庫都支持 MySQL 搬千, 因此, 先選用 MySQL 5, 待資料庫供不應求時再轉用企業級資料庫是個不錯的方案.
        一般中小企來說, mysql 已經應付有餘.

        PostqreSQL 亦是開源的免費資料庫. mySQL不同的是它可同時應付的要求約有120. 但速度比mysql . 现在 PostqreSQL mysql 同样接受到 SUN – microsystem的支持. 效果很值得期待.

      3. Support team availability 支援人員可靠性

        [] 相信是IT 界中最昂貴的開支. 俗語說買一塊錢的硬件則需要四塊錢的維護費. 維護誰來做呢 ? 當然是技術人員.

        支援人員可靠性就是說, 你的伺服器需要人隨時侯命, 在重要關頭 – production period 不容有失. 而且支援人員一定要有相關的專業知識.隨便幾千塊月薪請來的幫手可會累事呢 !

        因為好的技術員價值不菲, 市面出現了外判 – outsource 這情況. 就是說把自己的IT 部交給別的公司管理. 在可靠性上, outsource 有利有弊. 就是說當危急關頭時, 遠水不能救近火. 亦因為遠水不能救近火, 一些如ibm的大公司, 會把自己的技術員借到別的公司去. 可惜, 一般中小企就受不起這些天價的服務了.

        那中小企應該如何是好 ?

        先了解自己的需求, 例如24 小時侯命的支援與辦公時間侯命的支援價錢上是有天壤之別. 新公司的話,除了 outsource 還有 in-source 這樣的一個做法. 把一些專業人才拉來當作自己的一個部門, 但在行政上, 是兩間公司之間的合作. 當然, 這樣要跟別人分利潤, 但就可享有最高的可靠性.

      4. Backup 備份

        很多人都清楚什麼是備份吧. 備份是維持伺服器可靠性最重要的一環. 因為人和機器都免不了差錯. 而除錯是一件很費時的事, 最簡單的方法就是還原到上一個穩定的設定.還原時會造成資料流失,因此, 資料需要定期的備份.

        除還原外, 備份對災難性救援都有幫助. 簡單的例子如火警, 地區性停電.

        一般中小企常用的是increment backup, 就是說一整次備份所有東西, 之後沒有改動的資料不更新, 只更新有改動 / 新增的資料. 更新分每小時, 每日, 每星期,每月作不同程度的更新. 這個做法可以節省存儲資源和時間.

        在災難性救援方面, 需要異地備份. 例如需要準備兩套伺服器在不同電網的地方. 兩套伺服器作一個同步化. 當大停電時, 兩套伺服器不會因為在同一電網下停止運作.

        備份的完整性與異地備份是需要一些額外資金作支持, 所以都是視乎商業考慮而定.

      5. Crisis response time 危急救援反應

        用以上大停電的例子, 危急救援反應就是說停電後,需要多少時間令系統回復正常. 上面備份的例子中, down time < 1 . 因為有多一套伺服器作準備. 但試想想, 當只有一套伺服器時, down time = 停電時間+ 系統開動時間+ 資料回復時間. 這個時間中, 你的損失是多少 ?

        這個例子已足以說明危急救援反應對整個系統可靠性的影響.

        以前在銀行工作的時侯, 因為伺服器都是很昂貴的, 不可能準備兩套. 他們的做法是準備儲電器和發電機. 而且在同一個地方作資料.因此,備份當停電時, 系統只會斷電約一秒. down time = 1+ 系統開動時間+ 優化的(資料回復時間) 但在重要的伺服器, 他們亦是需要兩套伺服器.

        希望再減省這個成本的話, 虛擬化, 可以幫忙.

      6. Monitor system 監察系統

        監察系統就像你的眼睛,它會警告你伺服器出現問題, 在什麼地方出現問題. 而且會儲存一些數據, 用這些數據可以測到你的伺服器什麼時間最忙, 什麼時間不太需要技術員值班, 哪裡需要更新/ 升級, 你有多少客人 因為這樣, 監察系統可以幫你節省開支

        所以說, 監察系統是必需品. 這個必需品需要放在跟伺服器群不同的地區. 當災難發生時, 不會跟伺服器一同停止. 我這裡有一個正在使用的監察系統作示範

        http://monitor.yubis.org/

      7. Redundancy 後備

        正確的商業策略, 什麼時侯都需要後備. 應用在 IT 上都是同等意思. 當然愈多後備愈昂貴. 但最起碼給最重要的部份一個後備.

        除以上說的後備伺服器外, 其實路由器router和寬頻公司– isp都需要後備. 試想想你的家門口倒窒了, 什麼都不能出入. 這情況就像路由器當機和isp 公司出錯.

        怎樣去作路由器的後備 ? 不是由 isp 來的只有一條電話線嗎 ? Cisco 的路由器有一種方法叫 HSRP, 可以幫忙設定備用路由器的.

        看完以上的例子後, 相信你對你的 IT 預算已經心中有數

如有疑問, 歡迎跟我聯絡 funnykeith@gmail.com / MSN: funnykeith@msn.com

下一文章將會介紹準確性