Di dalam dunia distributed system ada beberapa istilah yang mirip-mirip tapi sebenarnya digunakan dalam konteks yang berbeda.

Load sharing bertujuan untuk membagi-bagikan pekerjaan dari satu atau beberapa sumber pekerjaan kepada satu atau beberapa pekerja sehingga tidak ada satupun pekerja yang tidak mendapat pekerjaan dalam suatu waktu.

Load balancing bertujuan untuk menyamakan workload pada seluruh mesin pekerja.

Task scheduling adalah kegiatan untuk membagikan pekerjaan ke pada banyak mesin pekerja secara optimal dengan memperhitungkan beban kerja, kecepatan kerja, dan lain-lain.

Parallel computing bertujuan untuk melakukan sebuah pekerjaa dengan membagi-bagi pekerjaan besar tersebut menjadi pekerjaan-pekerjaan yang lebih kecil dan mengerjakannya secara paralel.

Apa mereka itu dan bedanya di mana akan gw coba jabarkan satu per satu di postingan selanjutnya. ^_^ (ntar kalo sempet)

רציפות עסקית (uptime) או אפס זמן השבתה (zero downtime) היא הגורם המניע החשוב ביותר בתכנון ובהפעלה של מרכזי נתונים כיום, מפני שהעלות של כל דקה שהמערכות מושבתות היא אלפי דולרים. חברות המפעילות מרכזי נתונים ברמה 3 וברמה 4 מחזיקות גם באתרים מרוחקים וגם באתרים משותפים (co-location facilities) שרתים אשר חיוניים לתפקודה השוטף לא פחות מהשרתים הממוקמים באתר הראשי. כדי להבטיח רציפות עסקית יש צורך בפתרונות חדשים וחדשניים. אחד הפתרונות הוא יחידות חכמות לחלוקת זרם בארון (CDU – Cabinet Power Distribution Units) שיכולות לספק יכולת הסרת עומסים חכמה (Smart Load Shedding).  הפתרון מבוסס על CDU של חברת    Server Technology               
הסרת עומסים חכמה מאפשרת למפעיל להסיר עומסים על סמך שלושה משתנים תפעוליים חשובים: 

1) האם האל-פסק פועל מהמצברים
2) הטמפרטורה בארון עולה מעל המותר
3) העומס הנוכחי עולה על המותר

 משתני המפתח הללו מאפשרים למשתמש לקבוע מראש אילו מכשירים אינם חיוניים לפעילות השוטפת, להסיר אותם במקרים שמתעוררת בעיה ובכך להבטיח רציפות עסקית ולהגן על המכשירים החיוניים שבתוך הארון.

מי שמעונין ב white paper המלא שכתבנו בנושא זה מוזמן לכתוב לי ל yigals@schneider.co.il ואשלח לו / לה במיידי.  כמו כן יש דיון בנושא יישום נכון של  יתירות ב PDU בפוסט קודם

חג שמח

The Internet in mid 80s and 90s was envisaged to work on the IP destination based routing/forwarding paradigm. This meant that the routing protocols would establish the best paths based on some scalar metric like the hop count, or link costs, and all traffic would follow that path. This would work since all IP routing and forwarding was based on the IP address carried in the IP packets. With all due respect and credit to the Internet’s forefathers, the vision and the design did work, till a few years back, when the network operators started realizing that though the IP architecture was indeed scalable, it lacked the finesse to optimally utilize the network resources (particularly in the backbones).

The inadequate utilization of the network resources can be illustrated with the classic “fish problem“. It derives its name from the network (Fig 1) resembling a fish, with A being the head and G and H, the tail of a fish.

All traffic emanating (or passing through) from the tail, (G or H) towards the head (A) can take either of the two paths (F-D-C-B or F-E-B) based on how the IP routing tables are programmed by the routing protocols. The latter decide on the best path by considering the link costs advertised by each router in the network. In this example the total cost of path G-F-D-C-B-A is (10+5+5+5+10) 35, while the cost of the path G-F-E-B-A is 30. This means that all traffic from G to A (or G to B) would follow the path through router E (as shown by the red arrow), and the F-D-C-B path would remain unused, since the total cost associated with it is higher than the one through router E.

This leads to an extremely unbalanced traffic distribution, where the link F-E-B can get heavily overloaded, and at worst, congested, while F-D-C-B always remains idle. This problem arises because of the way IP routing paradigm works. Lets us see why:

o IP routing is destination based, so packets are only routed based on the destination IP address in the packet. Routing protocols typically install one next-hop for each IP address (except in case of equal cost routes, which we can ignore for the time being) or a range of IP addresses (subnet masks) thus all packets sharing the same destination address would all get routed to the same next-hop. This means that if F installs a route 100/8 with next-hop as E, then all IP traffic falling under 100/8 coming to F, would get routed to E. This can lead to unbalanced traffic distribution and create unnecessary congestion hot spots.

o Routers make a local decision, based on what they think is the most optimal path from their perspective, when selecting a path. Since all routers run the same SPF algorithm, with the same lin state database, they all come up with the same shortest path, which very soon turns congested, while the non-shortest path remains idle, and unused. This implies that to optimize the network utilization the routers must factor in some other things before chosing the path. One thing that comes instantly to mind is the total bandwidth available on each link when computing the path. If routers can somehow keep track of the available bandwidth available on each link, then it can distribute the traffic in a manner which can optimize the network resource utilization.

Coming back to our network, we find that all traffic from tail to head flows through the router E, leaving D and C idle. So, what can be done to fix this?

The operator can manipulate the link costs on path F-D-C-B, in a manner as shown below, to get the traffic to flow over it.

This clearly works, since cost of the path F-D-C-B (9) is now lower than path F-E-B (10). But hang on. What we’ve only achieved is moving the entire traffic from path F-E-B to F-D-C-B! The traffic would soon start congesting the latter link, while leaving the former unused. We have really achieved nothing, but have only moved the problem elsewhere. Clearly, this wouldn’t work. So, what else can be done?

Well, not much. A clever network operator can play around with the link costs on paths F-D-C-B and F-E-B such that both become equal, as shown in the figure below.

This would surely alleviate the problem as the two paths would now be equally used. However, this scheme of manually adjusting the link costs is not scalable and only works for small networks. Imagine replacing C, D and E with hundreds of routers, with a subset of them being connected to each other. The precarious scheme of adjusting the link costs would become too complex and too fragile to work. A single link (or a router) failure or a cost change would bring down the entire scheme of distributing the traffic across two paths.

The only scalable solution for the fish problem is by going beyond the realms of traditional IP routing and by providing mechanisms to explicitly manage the traffic inside the network. This new paradigm of routing is called constraint based routing, which essentially strives to compute the best path without violating any of the constraints imposed on the network, and at the same time, being optimal with respect to some scalar metric (hop count, links costs, etc). Once such a path is computed, it establishes and maintains forwarding state along such a path.

This differs from the existing IP routing paradigm which only tries to optimize (by minimizing), a particular scalar metric when computing the best path to a destination. Thus RIP optimizes the number of hops and OSPF/IS-IS, the total path cost, where total path cost is the sum total of individual cost of all the links along the path.

I would discuss more on constraint based routing in my subsequent posts.