web host (網頁代管)

利用資料中心的電腦群集和儲存裝置為使用者提供免費或收費服務，除了是共用同一台實體機外，也分享著同一個系統資源的關係。等於是在同一台電腦裡不同的使用者帳戶”同時“使用一樣的電腦資源(你多用另一人就只能少用的概念)。

特點

(a)
國家、公司，或任何網路對特定 ip ranges 出現 block access，舉例、go daddy 對 fb, youtube 進行 block
(b) 安全性
SFTP 對你所有的流量(traffic) 進行加密，unlike FTP。這對帳密這類型的資料來說是很需要的。
註：SFTP (Secure File Transfer Protocal），即檔案加密傳輸協議，傳輸預設的 port 為 22，傳輸需經密碼安全驗證，SFTP 是 SSH 的一部分
(c) 標榜無限制儲存空間
雖然打著無限制的儲存空間，但若有其他使會用同樣的機器來瓜分資源。因為 Web Hosting 除了是共用同一台實體機外，也分享著同一個系統資源，你一但超量就有可能影響到其他使用者的效能。

vps (Virtual Private Server)

是將一台實體伺服器分割成多個虛擬專享伺服器的服務，就像是出租套房，花錢租到的不僅僅只是一個床位，而是擁有了包含衛浴、電話、網路..等等的設施，每個VPS都可分配獨立公網IP位址、獨立作業系統、記憶體、CPU資源，等等，也可以做獨立的排程來和其他系統做到實際上的隔離。

vps do is they take generally super-fast server with lots of RAM, lots of CPU, lots of disk spaces, and they chop them up into the illusion of multiple servers using sth called hypervisor(讓很多虛擬的機器可以在實體機器上運作)。

差異：
sharing resoures in different ways instead of getting some slices of hardwares to yourself and no one else has user account on that particular virtual machine。除了你自己和 vps公司外，其他人是看不到你的資料。如果需要更多的隱私，就必須用自己的伺服器。

差異整理

• sharing resoures 的方式不同
• 價格不同

參考資料 :
【文章筆記 】CS75 (Summer 2012) Lecture 9 Scalability Harvard Web Development David Malan
[不是工程師] 架站用VPS還是Web Hosting，中文翻譯都有「虛擬」到底差在哪？

如果有一天網站規模變龐大，如何 scale your site，讓他可以負荷與處理這樣的狀況

解決方式

1. vertical scaling
2. horizontal scaling

垂直擴縮（vertical scaling)

為你現有的網站主機加上更多 CPU 或 RAM 等運算資源，使你的伺服器變得更強大。換句話說，它的意思就是「升級伺服器」，讓你伺服器的運算能力可以承受住更多工作負擔。

Why is vertical scaling not necessarily a full solution.

缺點 : 升級有上限 (there is a sort of ceiling)，因為你的財務有上限、目前的技術有上限，這些都會導致這個解法無法解決你的問題。

應用 : quard-core in server
with single-core machine you can only handle one web request at a time, now you could handle at least four at a time truely in parallel. the server will typically spawn what are called multiple processes or multiple threads so in reality you're handling many more than even four requests per second.

水平擴縮（horizontal scaling）

accept the fact there's going to be the ceiling eventually so why don't we instead archetict our system in such a way that we're not going to hit them rather we can kind of stay below it by using not state-of-the-art hardware but cheaper hardware. (不是購買一台最貴最先進的機器，而是藉由多台便宜的機器去達到類似的效果)

水平擴縮（horizontal scaling）指的是增加伺服器數量，讓原本只由一台主機處理不來的龐大工作負擔改為由多台主機一起分擔。水平擴縮通常會「複製」你現有的主機規格並產生多台同樣等級的伺服器來協助運算。

不僅如此，水平擴縮還有一個特性，就是它可以根據你現有的工作量來增加或減少主機數量。它會在工作量大時增加主機數量，反之則減少主機數量，藉此盡量避免讓主機因為沒事做而進入閒置狀態。

if we get an inbound HTTP request, we somehow want to distribute over all the various web servers that we might have 200 webserver or 2 webservers, the problem is still the same.

參考資料 :
電子商務面面觀 #03
影片 13:00 ~ 21:00

load balance

把用戶請求分發到多個伺服器上，利用多台伺服器提供單一服務，處理資源分配的問題
分發方法

traffic from the internet is somehow distributed or balanced across our various back-end server.

so it might be a case, server 1, server 2,... have unique IP addresses, but now when user type sth .com and hits enter,

what IP addresses should we return ?

instead of DNS returns IP addresses of server 1 pr server 2, you could instead return the equivalent of the ip address of this black box the load balancer and then let the load balancer figure out how to actually route data to the backend server.

優點

一、資料的隱密性
load balance 的 ip address 是 public，後端 server 的 ip address 是 private.
private IP 與 public IP 差異在於 rest of world 是否可以看到這個 ip，所以，private can't see private ip addresses, 既然無法看到也就意味 those servers by nature of this privacy can't be contacted at least directly by random advarsaries bad guys on the internet.

二、克服 Public IP 不足
the world has been running out of version four IP addresses, so it just hard or sometime expensive to get an enough IP addresses to handle the various servers that you might buy.
透過這樣的方式，我們只需要一個 Public IP ，而不是多個。

如何分派 request

前言：
the load balancer decided whom he wants to send the packes server one or two ..., and you can make this decision based on any number of factors.

直觀處理方式：基於負載情況分發
Actual propose doing it based on load like who is the busiest versus the least busy.
(load balancer 如何分派 request，視 load 決定。會將任務優先分給不忙的 server 處理。假設 load balancer 藉由相同的 tcp/ip 送出請求給 server one，接著 server one 開始處理請求，處理完請求後，將 response 傳給 load balancer，load balancer 再將 response 傳給 clients)

note：load 事實上表示 server 的忙碌程度。<參照: cs 75 lecture 0>

缺點 : 因為使用了 horizontal scalability，所以產生了運算上效能的損失。

模型假設 server one, two ... all need to be identical have the same content, 但對於你發出請求給底層的來說這很不必要，因為你使用了 n times this much disk space。

改進方式 : Instead, you can have dedicated servers

these is for HTML, these is for JS, you can do that just by having different urls, different hosts names. This is for instance img.sth.com, this is video.sth.com and the load balancer can take into account the host HTTP headers to decide which direction it should go.

處理方式二：Round robin 輪巡
輪流使用伺服器，可以平均的把每一個伺服器都用到
load balancer maybe just a fancy DNS set-up, whereby instead of returning the IP address of the load balancer itself, maybe instead of the DNS server just returns the IP address of server one the first time sb asks for sth.com, and the next time sb requests sth.com it returns the IP address of server two followed by sever three and wrapping around eventually to server one again.

缺點 : 可能某一台會遇到用量大的使用者

one of the server could just get a really real power user, but over time server one might just happen to get more heavyweight users than others servers. Round robin is still going to keep sending more and more users to that servers one end of the time just by nature around of robin.

if you want to uniform distribution across all n servers then the DNS servers has to return another responses.

there is no reason for ie, chrome to send the same DNS request evey single time, you are going to lose some number of millionseconds every time that happened or worst yet a second or two. so instead your operating system catches those responses, so does your browser, which means you don't need to do those lookup.

所以對於大量工作的 power users on server one, the next guy will be send to server two, not you.

So the caching to can contribute to a disproportionate amount of load on certain servers largely in due to bad luck.

In DNS there is an expiration times called TTL, is time-to-live-value with an answer from a DNS server, that it's typically an hour or five minutes (取決於 dns server 管理員制定的過期時間)，通常對於 power-user server one 過期時間會介於幾分鐘~幾天，直到你的 ttl 過期。

處理方式三：隨機
好處是不用擔心 catch 的問題，因為 dns server 只會回傳一個 ip，但壞處是可能會將太多的負擔放在一個 server 上。

shared session state

session 機制會在 php 裡面壞掉，如果我們後端的 server 是 php websites ，and they are using session superglobal，則 load-balancing seems to break this model.

recall:
session tend to be specific to different machines. your session might be sitting on the hard drive of server one, yet if by random chance you are sent by a round robin to server two or server three, instead of server one. In the worst case, you can see the same website, but you're going to log in again.

假設你在不辭辛勞，在每個 server 都留下了你的 session, cookie。如果 sth.com 是購物網站，然後你在購物車加入商品，你在不同裝置的購物車都放入不同的商品，當你確認結帳時，為甚麼商品不會加總在一起 ?

解決方法、dedicated servers under horizontally scaled

if we have horizontally scaled in the sense that we factor out disparate servers, this is our php server, this is our html server. Indeed, this problem would not arise because presumbly all the php traffic would get ready to php server.

缺點 :

一、專責的伺服器掛掉，那個 part 的東西就全掛了
there is no redundacy which is not good for uptime if anything breaks.
二、單一 PHP SERVER 處理的 LOAD 有限
as soon as you get popular you have too much load for single PHP server, then we have to solve this problem anyway.

as much as sessions are typically implented per server in the form of like a text file like we saw in slash temp, 這時 round-robin, low-true load balancing, 怎麼辦呢 ?

解決方法一、factorization

運用 factorization 的概念，不只對於各種不同類型的檔案，還使用在 services 上，例如 : sessions 的狀態。

so if we instead had a file server, like a big external hard drive. It's connected to all of the server. So, anytime they store session data, they store there instead of on there own hard drive. Then this way, we could share state. (可以將 session 架在 load balancer 上或一個新的機器上。)

現在，如果架設的機器壞掉了，整套機制就廢掉了~

假設我們有 n 個 servers，他們不會同時掛掉，所以我們有很好的 redundancy in our server model。但對於現在引入的 db 或 file server for our sessions, 如果他掛點，我們何苦花錢設置這些後端的 servers，因為整個網站就死掉拉 !如果 login 機制壞掉，沒有人可以線上買任何東西。

解決方式：raid (容錯式磁碟陣列)

• raid can be used in desktop computers these days.
• different forms : raid0 / raid1 / raid5 / raid6 / raid10 ...
  (all of these variants of raid assume that you have multiple hard-drives in your computers for different purposes potentially.)

the theory behind raid is that you can then run to the store buy another hard drives that is at the same size or bigger plug it in your computer boot backup. The raid array will rebuild itself whereby all of the data that's on the remaining drive will copy itself automatically over to the new one and after minutes or hours you're back to a safer place.

raid1 and raid0

two hard drives that are identical size and do stripe data across them whereby the evertime the operating system wants to save the file especially big files. It will first write to this drive a bit then to this one then to this one. The motivation being these hard drives are typically large and mechanical with spinning platters. (strip 可以讓我在兩個硬體間來回寫入資料，因為硬體數量是二，所以速度會提升兩倍)

raid0

優點、performance 最棒
(RAID 0的速度是最快的。但是RAID 0既沒有冗餘功能，也不具備容錯能力)

raid1

優點、資料備份 (只要一個磁碟正常即可維持運作)
缺點、寫入速度略下降
you mirror data so anytime you write down a file, you store both places simultaneously, there is a bit performance overhead to write it in two places albeit in parallel. However, the upside now is that either of these drives can die and your data is still perfectly intact.

raid5

raid5 is little more versatile whereby I typically have say three drives, four drives, five drives, but only one of them is used for redundancy.
僅犧牲 1/5 的硬碟空間，相較於 raid1 犧牲 1/2

raid6

any two drives can die, you still don't lose any data.

raid10

優點、striping and redundancy
缺點、花費更多(因為你需要更多硬碟)
raid0 和 raid 1 的結合。
use four drives and have both striping and redundancy

使用這項技術的好處、help with uptime and robustness

in file server we're storing our shared sessions is we can at least decrease the probability of downtime(停機時間) at least related to hard disk. Unfortunately, it's still has power code(電源線) that someone could trip over, or the power supply that could die, it's still has RAM that colud go on a fritz(故障), any number of things still happened. But at least, we can throw reduandancy inside of the confines of a single server.

參考資料
維基百科 raid

對於電腦來說擁有多個硬碟(hard drives)、多個 RAM、多個 power supply 是很常見的。

someone trip over all the power codes 如果後端 server 掛掉上述的方法就會故障。所以在這個狀況下，我們可以怎麼做保持原本 shared state ?

Sticky Sessions

定義

附載平衡會看使用者丟過來的 Session，決定這個封包是否要再丟給相同的機器，這樣的行為就可以解決Session亂跑的問題。

sticky sessions meaning that when you visit the website multiple times your session is somehow preserved even if there are multiple backend servers. More specifically, you are still going to end up on the same back-end server.

前言

we talk really about things as a file server but it can be incarnated with very specific technologies.

shared storage

FC

優點：超快
缺點：超貴
使用地方：資料中心、辦公室

iSCSI

uses IP and uses Ethernet cables to exchange data with servers so that's a somewhat a cheaper way of exchanging of having a shared file server

mySQL

it's already seperate sever potentially. just because we usually store things like user data, doesn't mean we can't store metadata like our cookie information as well.

NFS

it's just a protocal that we can use to implement the idea of a shared file system. You've got one server and you're exposing your disk to multiple other computers.
參考資料
AWS ELB STICKY SESSIONS

So shared storage was the idea we really vetted quite a bit and we didn't quite get to a perfect solution since we even though factor out the storage and put everyone's cookies and sessions on the same server. we feel like we need some redundancy.

cookie

cookie could offet the solution to sticky session.

storing everything in cookies probably bad because

1. violate privacy (相較於儲存 key 你存的是 like the ISBN of all the books in your shopping cart.但這些東西，你的室友、家人可能一點都不想知道)
2. cookie 的大小有限 (few kilobytes)

但，你可以存 server 的 id 進入 cookie 中。
so the user the second, the third, the fourth times they visit your website as by following links or coming back some other times they are going to present the equivalent of a hand stamp saying hey I'm the backend-server1 send me there again.

缺點、ip changes
we just put like the back-end IP so the private IP address and the cookies you don't know what the IP changes. Besides, you don't need to reveal to the world what your IP address schema is. It's not necessarily sth they could exploit.

透過在使用者的電腦上儲存 cookies 與運用 php 的方式儲存一個 big random number 然後讓 load balancer 記住後端 server 對應的 big random number

優點、解決 ip changes 狀態改變與避免 cookie 被有心人士操控
we're not putting any states that might change or might be a little privacy revealing on the actual user's computer. Moreover, we just take away the ability for them to spoof that cookie just to get access to some other server now.

結論：so cookies indeed are sth that these black boxes of load balancers tend to do whereby you can configure them to insert a cookie themselves. It doesn't just have to be a back-end web-server that generates cookies. The load balancer similarly can be inserting a cookie with a set-cookie header that the end-user subsequently send back so we can remember what back-end server to send the user to .

當然，如果 users' cookie disabled，整個系統就會死掉。 => 這邊超過這堂課程討論的部分!

database replication

仍然沒有解決 share of downtime 的問題。最直觀去解決 single file server 會掛掉的方法是甚麼 ?

一個會掛掉，裝兩個就好了壓。
somehow you have to figure out how to sync the two so one has copy of the others data and vice versa. => replication

PHP Accelerators

php 比起更底層的語言 C 效能相對不佳，但有些方法可以提升 PHP 的 performance => php acceleration

PHP加速軟體是一種將PHP程式碼編譯之後所產生的bytecode暫存在共享記憶體內供重複使用，以提升執行效率的外掛程式軟體

you can run a php program, a scourse code through php.exe the interpreter on the system and it turns out that PHP does compile that file in a sense down to sth that's more efficiently executed much like Java compile sth down to sth called byte code. Typically, PHP throws the results of that compilation away whereby it does again and again for every subsequent request.

當有人第一次到你的網站時，php 會被編譯且 op code 也會被生成，但這些東西不會被丟掉，因為當下一次又有人拜訪這個網站，php 檔案不用再重新編譯，op code 可以直接執行，透過這樣的方式效能因此被提升。

優點、效能提升
especially handle all the more requests per second in the context of PHP based website.
缺點、
如果改變了 .php 檔案，必須丟掉原本的 cached op code。但基本上 PHP 加速軟體會幫你做完這些事情。

caching 快取

in general is a great thing solve some of our DNS concerns early on.

應用

cach can be implemented in the context of dynamic websites in a few different ways.

缺點、
caching can be a bad thing if some value has changed but you have the old one.

.html

產生 html 然後 saving 一些叫做 .html 並把他們儲存在 disk (磁盤)

舉例、

Craigslist is spitting it out as .html file as opposed to storing it where or what ?
it's a stark contrast to what we've done for project-zero, project-one. we're using php as a backend whereby you store data like server-side and maybe a XML file then you generate a page like this dynamically.

所以為甚麼 Craigslist 要這麼做 ?

if they're restoring the HTML file, they just don't need to regenerate it every time it's visited.

優點、
that web-server like Apache that are really good and fast at just spit out raw static content like gift, jpeg, and a HTML file. All you have to do is response to a tcp-ip request with bunch of bytes from disks. Hence, they're taking advantages of the performance persumably of serving up static content, but this comes at a cost.

what's is the downside of this file based caching approach ?

缺點、

• space (x)
  wer're storing it on disk if you've posted on the Craigslist they're storing somewhere in the db because they do let you go back and edit it.

• more disk space (O)
  there's a redundancy well actually with all these thousands of files. there's a redundancy to just in the basic stuff like you have the same HTML tags, the same body tags, the same link tags, the same script tags in every single pages if they're indeed just static HTML files. So whereas you get some benefit of using some like php and recall our MVC discussion where we factored out our template codes like header and footer so that we stored in one place and not thousands of places. Craigslist are just like scarificing this feature and going with this instead.

it's a trade-off. 藉由 serving up the static content 獲得了更好的效能但卻需要付出更多的磁碟空間 (disk space)，但更大的缺點是如果你產生了 tens of thousands of Craigslist pages, what's is the implication now ?

• 重構 html 超不易 (O)
  if you want to change the aesthetic of the pages and add a background color, change the css, or making the font, it's no-trival now.
  Because assuming this is fully intact HTML file with no server-side include mechanism like you have in php, you have to now change the background color in tens of thousands of files unless maybe you put the css file, but even then it's a less trivial change in color.
  假設你想重構整個 html pages, 會出現大量的取代或需要重新產生爆量的頁面。

.MySQL Query Cache

當 MySQL 執行 SELECT 查詢時，會將結果放到 Query Cache 內，當下次執行相同的 SELECT 查詢時，不會在資料庫查詢結果，而會在 Query Cache 取得，從而提高執行效率。當資料表被更動後，儲存在 Query Cache 的 Cache 會失效，MySQL 會在背後將 Cache 刪除及重新建立 Cache。所以如果資料表是經常更新的話，Query Cache 反而會使系統的工作量加重。但如果你的資料表及裡面的資料很少更動，那麼開啟 Query Cache 確實有一定作用。

• 使用方式：
  it's easily enabled on a typical server with mySQL. there's a file called my.CNF for your configuration file. you can simply add a directive like query catche type equals one and restart the server to enable the query cache.

• 使用場合：
  if a user is navigating your website going forward and back quite a bit.

參考資料：
為什麼要關閉 MySQL Query Cache

memcached

it's a mechanism to store whatever you want in RAM

memcached is a memory cache so it's a piece of software. You run on a server. It can be on the same server as your webserver, and it can be on the different boxed altogether.

do select * from users 很耗效能，因為在資料庫的表中 users 有百萬個以上，所以我們一點都不想常常執行這種耗效能的 query，如果可以只執行一次，將執行完的結果放到 RAM，然後下一次我需要這個 users 時，我就去 RAM 裡面的 cache 找而不是去資料庫中搜尋百萬筆 users。

so there's this sort of tier of performance objectives. Disk is slow (spinning disk esp slow) but it's fast to serve up.

所以你一點都不會想將資料存入磁碟當中，你會想將資料存到表格中，藉由索引讓蒐尋變得更快。舉例、xml 檔案雖然很小，但你要 search it，必須先從磁碟載入、透過 xml api build up the dom、最後才是 search it。但這些步驟超煩，如果可以跳過 disk step，整體速度會更快。因此，mySQL 這個 server 誕生了，他透過 RAM 持續地運作，所以在這個案例下你執行的 query on data 是在 RAM 裡面。 even if it isn't at least you have the opportunity to define the indexes so that you can search the data more readily than you can with say XPath in XML.

A memcache in this case is a key value storage mechanism.

Next time I want to look up this user I want to look him up by his ID and case-in-point what I did in line two.

$memcache = memcache_connect(HOST, PORT); // 先連到 memcache server
$user = memcache_get($memcache, $id); // get sth from the cache，第一個參數是 reference to the cache 
if (is_null($user)) // when user is not in the cache. 
{
 $dbh = new PDO(DSN, USER, PASS); // 連到資料庫
 $result = $dbh->query("SELECT * FROM users WHERE id=$id");
 $user = $result->fetch(PDO:FETCH_ASSOC); // 呼叫 fetch to get back in associative array of  mydata the user's information
 memcache_set($memcache, $user['id'], $user); // storing key value pair in the cache whereby the key is user's id, and the value is the user object itself
}

小結、
相較於 cache (which is just key value store)，資料庫的 QUERY 非常的耗能

cache is finite since RAM is finite and even disk is finite. Therefore, what could happen eventually with my cache ?

eventually, the cache could get so big you can't keep it on the machine so what would be a reasonable thing to do at the point when you've run out of the RAM or disk space for your cache ?

we use garbage collection.

運用 FIFO 先進先出法 (if this object has not been needed since by constraints)
we can essentially expire objects based on when they were put in so if I put user=123 yesterday and I haven't touched him since or needed him since and I need more space well out user=123 so I can reuse the space the memory for user=456.

for power user
如果 user=123 頻繁地登入(power user)，我們可以記住每一次我獲得 catche hit，然後我確實在 chache 裡找到 user=123。我可以執行另一個 memcache function that just touch the user object so to speak thereby updating their time stamp to be this moment in time. Thus, you remember he was just selected.(實際上 memcache 會幫我們做這個。)

應用
FB is more read heavy, which makes cache is more compelling because if your own profile isn't changing all that often, at least you might get 10 pages views by friends before you update your profile. Again, there's a opportunity for optimization.

臉書使用 memache 這項技術，他們就不用為了呈現出你的頁面，常常進他們的資料庫撈資料，相對地他們呈現出頁面是 some previous look up unless it has since expired.

MyISAM VS InnoDB

MyISAM : 使用 lock，不支援 transaction
InnoDB : 適合需要大量的寫入的環境、支援 transaction

mySQL storage engine

The storage engine was just like the underlying format that was used to store your database data.

除了 MyISAM 與 InnoDB 外，介紹以下幾種

• HEAP : 資料存在記憶體(ram)當中，最適合給暫存用的table。
  (優點、implement a cache 相對簡單，by writing keys and values into DB。可以藉由 cache 的方式，避免 touch larger table。)

• Archive : 儲存大量的資料，且又沒有indexes。
  (it's compressed by default so archive table are slower to query but they're automatically compressed for you so they take up min space. Hence, common use for archive table may be log table. 假設你幾乎很少 query the data，資料保存的原因是為了研究目的等等，所以我們會願意犧牲一點未來 query 的效能。)

• NDB: 叢集環境
  (use for clustering. there's a way to address the issue of single points of failure that we discussed earlier with shared storage.)

Replication: Master-Slave

making automatic copy of sth
master DB 是你主要讀資料寫資料的地方，master 透過網路的連接可以有一個以上的 slave DB，而 slave 的目標就是複製 master DB 裡的每一個 row。everytime a query execute on the master, that same query is copied down to one or more slaves and they do the exact same thing.

理論上，master and slaves are identical to one another。

in the context of FB esp in the early days how might they in particular use of this topology ? ie read-heavy >>> write-heavy

why this is a good topology for its website that is really read-heavy and less write-heavy ?

優點、

• 備份支援
  if database one die, you have three backups that are identical.

• 平衡 read request
  reading can be expedited (可以寫出任意的 select statements 到資料庫2, 3, 4 ...，對於任意插入、新增、刪除的 query，一定要到 server 1。儘管 query has to propogate two servers, 2、3、4 仍然不常見。而且這整個過程是自動發生的，所以 code-wise 不用擔心太多，如果你擔心效能可以架更多台 servers to lighten the load further， )

缺點、

• master 只有一台
  single point of failure at least for rights. ex、status updates for instance could be offline.

Replication: Master-Master

this time you can write either server1 or server2, and if you happened to write to server1 that query gets replicated on server2 and vice versa.

你可以總是寫在一號，query 會自動到二號去。或者你可以 write either thereby load balancing across two and they'll propogate to each other.

we're still having traffic route !

Load Balancing + Replication

webservers are typically called a tier a service tier.

缺點、
single point of failure : mySQL master, load balancer

小結論、單一 single-balancer 絕對是件壞事。

active-active mode

兩台（或N台）同時運作
with active-active, you have a pair of load balancers that are constatly listening for connections either one of which can receive packets from outside of the world and relay them to back-end servers.

what they typically do is they send heartbeats from left to right and right to left so that if this guys ever stops hearing a hearbeat from this guy so to speak and a heartbeat is just like a packet that gets sent every second or something like that.

如果一號停止 hearing 二號的 heartbeat，則二號會自動假設一號掛了(go offline)，同時二號會直接接手工作(he continues to send traffic from the outside word)

ative-passive mode

一台做活動的伺服器，另一台做待命伺服器，待命的機器，在活動機器正常運作時，基本上就是在那邊睡覺浪費電用。一般在講failover就是屬於這個，也是cluster HA基本款。

如果你是 active-passive 的模式，如果二號是 active 狀態然後他掛了，一號會發現他收不到來自二號任何的 heartbeat，則處於 passive 狀態的一號會做的事是將他的狀態升級到 active，換句話說他接收二號的 ip 。所以現在所有的 traffic 會直接導到一號。

... + Partitioning

現在透過介紹兩個 load-balancer，引入 partition 的概念。

partition is very common in database. you can still have redundacy a whole bunch of slaves but you can balace load on some high level user information not based on load / round-robin.

舉例、早期的臉書有 ntu.fb.com 和 nthu.fb.com
the earliest partitioning they use was essentially to have a different servers as Outsiders could tell for each school. Thus, they literally just copied the database, copied the files over to another server and then there was born nth's copied of facebook.

但一旦使用者爆量、學校爆量，會變得非常混亂。但最初的架構因為使用了 partition 所以變得非常清楚。

臉書沒有那麼大的 server 同時去處理台大、清大，既然如此一個 server 不行就用兩台 server 麻，其中一台負責台大、另一台則負責清大。

當業務規模擴大，透過 scale horizontally。

there's a catch of partitioning as you want to poke sb at NTHU or vise versa, you had to somehow cross NTHU/NTU boundary. But, it's a bad thing since we are in seperate database so early on there were some features that you can only do with your net-work not until there was more shared state.

High Availability (HA)

it can apply to databases as well. High Availability refers to some kind of relationship between a pair or more observers that are somehow checking each others' heartbeats so that if one of them dies, the other takes on the entire burden of the service that being provided whether a database or a load balancer.

we have a need for one or more web servers, one or more databases, maybe some load balancers.
考慮資安，必須再加上 firewalling

問題一

Q1：how do i implement sticky sessions ?
A1：use load balancer to store all the sessions in one place.

問題二

Q2：shared states that sounds expensive fibre channel ice since it sounds complicated. There's a simpler way how do I ensure sticky sessions using only a load balancer and no shared states yet ? 我要如何確定小明近來他會送到 webserver 一號，下次他再進來他還會被送到 webserver 一號 ?

A2：why don't we have the load balancer listen at the HTTP level and when the response comes back at the first web-server, the load balancer can insert some kind of cookie that allows it to remember that this user belongs to server one. it's a big random number, and it's got a table like php does for sessions and figures out which server to send her to in this case.

問題三

Q3 : 最簡單建立資料庫的方式就是 put it on the webserver itself，但這會有甚麼問題呢 ?

A3 : if 小明 just happens to end up on server one, and he updates sth persistent ex his profile, it's going to persist on database of server one (結果就是 sticky session 幫我們解決完這個問題)
但若很不幸，小明一個月後才回來或是他使用不同裝置登入，他最後在 server two，那小明的檔案、信用卡資料會全是空的，因為他在不同的資料庫。除非我們幫我們的用戶做 partition，這樣一來小明就會被永遠導入 server one，小明就完全不用在意 server two 的資料庫到底有沒有他的資料。

問題四

Q4 : instead of factor out the database, and say that it's not on the webservers and it's got some kind of internet connection here. what's is our problem ?

A4 : single point failure
解決方法：
(一)、slaves db
attach slaves databases of this, but it then involves some how promoting a slave to a master in the event one died.

(二)、multiple db
first, do master to master replication.

what's about these lines ? bad
(database on the same server as webserver bad because then it's only talking to it and if 小明 ends up to the other server he has no data that you're expecting. functionally, this is equivalent.)

so we need to have some kind of cross connect.

now, my load balancing has to be done in code if those are the only components of my system right now, the line suggests that ...one has a connection to DB-one and DB-two. 所以這也意味，我需要做 if 條件判斷在我的 php code。這不是一件壞事，只是對於開發者來說，他必須先知道這些 topology.

如果再架第三台主機，mySQL wouldn't play nicely on that，現在就必須要修改原本的 codes。=> this is not a nice layer of abstraction.

再加入一個 load balancer，對上連接 w.w.w. machines 對下連接 database servers，他會負責這兩個主機的 load balancing.事實上，對於資料庫來說，很難做到任何所謂智能的負載均衡，因為 mySQL traffic is going to opertate with binary messages not with HTTP style textual messages.

以圖來說，最前面的 load balancer 可以查閱 http headers 然後進一步做出智能的判斷，對後面的 load balancer 也許可以但要做到相同的事情是有難度的，maybe you probably push them into php codes again。

但還是存在著 single point of failure。

這種時候，你會使用 switches 或某種 Ethernet cables，他們的目的都是要 censor some central sourse。

why it's not a good idea if I plugging everything into a switches ?
但還是存在著 single point of failure。

welcome to nerwork redundancy!
servers, databases, web alike as well as your load balancers would typically have at two Ethernet jacks in them and one cable would go to one switch to another cable would go to the other switch.

透過 switches，you don't create this crazy mess where traffic is just bouncing and bouncing around in your internal network and nothing is getting in or out.

問題五

Q5：現在，將 load-balancer 也變成兩個，在 fix 了 single point of failure 的問題，還會有甚麼問題呢 ?

A5：here is the door to your data center。
the building itself burns down or goes offline you have some kind of network disconnect between you and your isp the whole building.

cloud computing refers to outsourcing of services and sharing resourses like power, net-working, security, and so forth across multiple customers. Amzon services EC2(Elastic computer cloud) is kind of this picture here whereby you don't own the server but you do rent space on them since they give you VPS is that happen to be house inside of this building.

Amzon offers things called avaliability zones whereby this might be an abaliability zone called US EAST ONE and what they offer two is US EAST TWO and three and four ....

現在，有另一棟跟這棟差不多的東西，理論上這兩棟不會一起分享相同

1. power sourse
2. net working tables

所以就算其中一棟出事了，另一棟也不會被影響。實際上 amazon 可能遭遇大區域的停電，但事實上 amazon 在西岸、歐洲、亞洲、非洲都有建置 data centers。

問題六

Q6：兩棟之間藉由 internet 進行連接，所以現在一旦有兩棟 data centers，要如何分配 load across two data centers ?

A6：you can do load balancing at DNS level and this is indeed how you can do geography load balancing whereby now someone in the internet requires IP address of sth.com. They might get the IP address at first building or more specifically of the load balancer in this building. 或者他們也可能拿到的是 ip 地址是在二號數據中心。

還記得嗎 ? nslookup on google，拿回超多 result，這些 result 表示的是不同的數據中心，他們可能在不同的國家，因此他們會有不同的 entry point、IP address。

still some issues

you have global local balancing then the request comes to the building and you still have the issue somehow making sure the subsequent traffic gets to the same place since odds are google is not sharing your sessions across entirely different continents. Besides, you have potential downtime cause if a whole building goes offline and your browser, your computer happens to catch the IP address of that building that data center could take some minutes, or some hours for your TTL to expire at which point you get rerouted to sth else.

但至少我們可以避免 data center 裡面的 single point of failure

security

what kind of traffic now needs to be allowed in and out of the building ?

What type of internet traffic should be coming from the outside world in and if i'm hosting a website with a lamp based website ?

I want TCP80 ! 但這會讓資訊安全產生一定程度的犧牲。why ?

因為你 block 了 一個非常有用的 traffic => TCP443 (which is default port that's used for HTTP/ SSL based urls)

所以現在只有 TCP80、TCP443，才能進得來。同時，你也將你自己擋在 data center 外，因為你不能利用 ssh 進入 data center。

因此，你會希望允許一些端口，像是 port22 for SSH 或你會想要有一個 SSL based VPN，讓你可以遠端的進入你的 data center。

要注意的是，這邊的 data center 也可以是 web-hosting company / vps company。

how about the load balancers what kind of traffic needs to go from the load balancer to my web servers ?

inside the data center, nobody else is going to listen to the people inside so you would want to drop the encryption ...

it's very common to offload your SSL to the load balancer or some special devices and then keep everything else inside unencrypted. Because you control this, it's at least safer not 100% due to your compromise.

doing the SSL termination. everything is encrypted from the internet down to here but then everything else goes over normal unencrypted HTTP.

優點、get cheaper webserver
you don't need to put all your ssl certificate on all of your web servers. You can just put it in the load balancers. 如果不這麼做的話，you can get expensive load balancers to handle the cryptography and the computational cost.

how about the traffic between the webserver and the databases ? perhaps through these load balancers ?

it's sql queries. tcp3306 ,which is the port number that mySQL uses by default.

甚麼意思呢 ?

If you do have firewalling capabilities and we haven't drawn any firewall per se so we do need insert some hardwares into this picture that would allow us to make these kind of configuration changes.

But if we assum we have that ability in large part because these things are plugged in as we said to some kind of switch. The switch could be a firewall itself. We could make this configuration changes.

We can further lock things down why ? Everything just works if i don't work firewall things. Why would I want to bother tightening things so that only TCP80, TCP443 are allowed here and TCP3306 is allowed there ?

there just no need for people to be able to potentially even execute sql queries coming in or make my sql connections.

Even if your're not listening for my sql connections, it again is sort of the principle of the thing that you should really have the principle of least privilege whereby you only open those doors that peopel actually have to go through otherwise you're just inviting unexpected behavior because you left the door ajar so to speak you left the port open.

In fact, if somehow you screw up or apache screws up or PHP screws up and this server is compromised. It's be kind of nice if the only thing the server can do is talked by MySQL to this server and can not for instance suddenly SSH to another server or poke around or execute any commands in your Network other than MySQL so at least if the bad guy take this machine over you really can't leave this rectangle here that I've drawn.

別滿足，仍然有很多尚未解決的問題

Beyond the scope of things we've done in the class and even thougn the appliance itself actually does a firewall allows certain ports in and out all of ones you need. We haven't defined tune it for any of the projects realize that you bet even on sth like a linux based operating system.