Patent process.docx

├── .gitignore ├── README.md ├── nom.docx ├── nom_substructure ├── word │ ├── map │ ├── webSettings.xml │ ├── fontTable.xml │ ├── _rels │ │ └── document.xml.rels │ ├── settings.xml │ ├── theme │ │ └── theme1.xml │ ├── numbering.xml │ ├── styles.xml │ └── document.xml ├── _rels │ └── .rels ├── docProps │ ├── core.xml │ └── app.xml └── [Content_Types].xml ├── parse.js ├── docxmap.json ├── package.json ├── LICENSE ├── docx.js ├── unzipDocx.js ├── out.html └── nom.html /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules/* 2 | !.gitkeep 3 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | docx2html 2 | ========= 3 | 4 | docx to html converter 5 | -------------------------------------------------------------------------------- /nom.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/artburkart/docx2html/HEAD/nom.docx -------------------------------------------------------------------------------- /nom_substructure/word/map: -------------------------------------------------------------------------------- 1 | w:p ==>

2 | w:r ==> 3 | w:pPr ==>

4 | w:rPr ==> 5 | w:b ==> 6 | w:i ==> 7 | w:t ==> literal text 8 | w:numPr ==>

and
or

9 | w:pStyle w:val="ListParagraph" ==>
and
or
10 | 11 | { 12 | "w:p": [] 13 | } 14 | newDoc = $(''); 15 | _.each(pars, function(p) { 16 | newDoc.append('
')q 17 | }); 18 | -------------------------------------------------------------------------------- /parse.js: -------------------------------------------------------------------------------- 1 | var fs = require('fs'), 2 | parser = require('xml2js').Parser(), 3 | et = require('elementtree'); 4 | 5 | var dom = fs.readFileSync('./nom.docx'); 6 | var newDom = {}; 7 | 8 | 9 | // // parse the body xml and return the blob of interest 10 | // parser.parseString(entry.getData(), function(err, result) { 11 | // if (err) return callback(undefined, err); 12 | // else { 13 | // var body = result['w:document']['w:body'][0]['w:p']; 14 | // return callback(body, undefined); 15 | // } 16 | // }); -------------------------------------------------------------------------------- /nom_substructure/word/webSettings.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /nom_substructure/_rels/.rels: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docxmap.json: -------------------------------------------------------------------------------- 1 | { 2 | "w:p":"
", 3 | "w:pPr":"", 4 | "/w:pPr":"", 5 | "w:rPr":"", 6 | "/w:rPr":"", 7 | "w:r":"", 8 | "/w:r":"", 9 | "w:t":"", 10 | "/w:t":"", 11 | "", 16 | "w:i/":"", 17 | "w:numPr":"
", 18 | "/w:numPr":"
", 19 | "w:ilvl":"", 20 | "w:numId":"", 21 | "w:contextualSpacing/":"", 22 | "w:spacing w:line=\"360\" w:lineRule=\"auto\"/":"", 23 | "w:pStyle w:val=\"style0\"/":"" 24 | } -------------------------------------------------------------------------------- /nom_substructure/docProps/core.xml: -------------------------------------------------------------------------------- 1 | 2 | Patent process.docxArthur BurkartArthur Burkart22014-02-22T23:55:00Z2014-02-22T23:55:00Z -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "docx", 3 | "version": "0.0.0", 4 | "description": "docx to html", 5 | "main": "docx.js", 6 | "dependencies": { 7 | "adm-zip": "~0.4.4", 8 | "xml2js": "~0.4.1", 9 | "underscore": "~1.6.0", 10 | "elementtree": "~0.1.6" 11 | }, 12 | "devDependencies": {}, 13 | "scripts": { 14 | "test": "echo \"Error: no test specified\" && exit 1" 15 | }, 16 | "repository": { 17 | "type": "git", 18 | "url": "git://github.com/Chachi-inactive/docx2html.git" 19 | }, 20 | "author": "Brian Gapinski and Arthur Burkart", 21 | "license": "MIT", 22 | "bugs": { 23 | "url": "https://github.com/Chachi-inactive/docx2html/issues" 24 | }, 25 | "homepage": "https://github.com/Chachi-inactive/docx2html" 26 | } 27 | -------------------------------------------------------------------------------- /nom_substructure/docProps/app.xml: -------------------------------------------------------------------------------- 1 | 2 | 0514428225Microsoft Office Word06819falseTitle1Patent process.docxfalse9648falsefalse15.0000 -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2014 Arthur Burkart 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 21 | -------------------------------------------------------------------------------- /nom_substructure/[Content_Types].xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | -------------------------------------------------------------------------------- /nom_substructure/word/fontTable.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /docx.js: -------------------------------------------------------------------------------- 1 | var unzip = require('./unzipDocx'); 2 | var body; 3 | 4 | unzip.getBody('./nom.docx', function(data, err) { 5 | if (err) { 6 | console.dir(err); 7 | } 8 | else { 9 | body = data; 10 | } 11 | }); 12 | 13 | //var body = obj["w:document"]["w:body"]["w:p"]; 14 | 15 | getParagraphs = function(data) { 16 | pars = [] 17 | for (var key in data) { 18 | if ('w:r' in data[key]) { 19 | pars.push(data[key]['w:r']); 20 | } 21 | } 22 | return pars; 23 | } 24 | 25 | exports.getParagraphs = getParagraphs; 26 | 27 | //var paragraphs = getParagraphs(body); 28 | //console.log(paragraphs); 29 | 30 | //for (var key in body) { 31 | // console.log(JSON.stringify(body[key])); 32 | // console.log("\n"); 33 | // //if ('w:r' in body[key] && 'w:t' in body[key]['w:r'][0]) { 34 | // // txt = body[key]['w:r'][0]['w:t'][0]; 35 | // // console.log(txt); 36 | // // //if (txt === 'string') { 37 | // // // console.log(txt); 38 | // // //} 39 | // // //else { 40 | // // // console.log(txt['$']); 41 | // // //} 42 | // // //else { 43 | // // // console.log(body[key]['w:r']); 44 | // // //} 45 | // //} 46 | // //else { 47 | // // console.log("w:r not a key!\t" + body[key] + "\n"); 48 | // //} 49 | // //console.log(body[key]['w:r']); 50 | // // if (Object.prototype.toString.call(body[key]['w:r']) === '[object Array]') { 51 | // // for (var k in body[key]['w:r']) { 52 | // // if (typeof(body[key]['w:r'][k]['w:t']) === "string") { 53 | // // console.log(body[key]['w:r'][k]['w:t']); 54 | // // } 55 | // // else { 56 | // // console.log(body[key]['w:r'][k]['w:t']);//["#text"]); 57 | // // } 58 | // // } 59 | // // } 60 | // // else if ('w:t' in body[key]['w:r']) { 61 | // // //console.log(typeof(body[key]['w:r']['w:t'])); 62 | // // if (typeof(body[key]['w:r']['w:t']) === "string") { 63 | // // console.log(body[key]['w:r']['w:t']); 64 | // // } 65 | // // else { 66 | // // console.log(body[key]['w:r']['w:t']['#text']); 67 | // // } 68 | // // } 69 | // //} 70 | //// else { 71 | //// console.log("NO MATCH!\n" + body[key] + "\n"); 72 | //// } 73 | //} 74 | -------------------------------------------------------------------------------- /nom_substructure/word/_rels/document.xml.rels: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /nom_substructure/word/settings.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | -------------------------------------------------------------------------------- /unzipDocx.js: -------------------------------------------------------------------------------- 1 | var AdmZip = require('adm-zip'), 2 | parser = require('xml2js').Parser(), 3 | _ = require('underscore'), 4 | fs = require('fs'), 5 | et = require('elementtree'); 6 | 7 | var XML = et.XML; 8 | var ElementTree = et.ElementTree; 9 | var element = et.Element; 10 | var subElement = et.SubElement; 11 | 12 | // unzip docx and get body text 13 | getBody = function(path, callback) { 14 | var etree; 15 | 16 | // path validation 17 | fs.exists(path, function (exists) { 18 | if (!exists) return callback(undefined, "Error: file does not exist."); 19 | 20 | var zip = new AdmZip(path); 21 | var zipEntries = zip.getEntries(); 22 | 23 | // grabs the body xml 24 | for (var i = 0; i < zipEntries.length; i++) { 25 | if (zipEntries[i].entryName === "word/document.xml") { 26 | entry = zipEntries[i]; 27 | break; 28 | } 29 | } 30 | entry = entry.getData().toString() 31 | .replace(/<\?xml\b[^>]*\?>\n/g, "") 32 | .replace(/[^<]*/, "") 33 | .replace(/[^>]*$/, "") 34 | .replace(/]*>(.*?)<\/w:t>/g, "$1") 35 | .replace(/]*>(.*?)<\/w:rPr>/g, "$1") 36 | .replace(/]*>(.*?)<\/w:p>/g, "
$1
") 37 | .replace(/]*>(.*?)<\/w:r>/g, "$1") 38 | .replace(//g, "") 39 | .replace(//g, "") 40 | .replace(//g, "") 41 | .replace(/]*\/>/g, "") 42 | .replace(/]*\/>/g, "") 43 | .replace(/]*\/>/g, "") 44 | .replace(/]*>(.*?)<\/w:hyperlink>/g, "$1<\/a>") 45 | .replace(//g, "") 46 | .replace(/<\/w:pPr>/g, "") 47 | .replace(/]*>(.*?)<\/w:sectPr>/g, "") 48 | .replace(//g, "") 49 | .replace(/]*>(.*?)<\/w:body>/g, "$1") 50 | .replace(/]*>(.*?)<\/w:document>/g, "$1") 51 | .replace(/]*>(.*?)<\/w:numPr>/g, "$1") 52 | .replace(/
<\/p>/g, "") 53 | 54 | // .replace(/ w:type="spell[Start|End]"/, "") 55 | // .replace(/w:type="gram[End|Start].*?\/>/g, "/>") 56 | // .replace(/w:rsidP.*?>/g, ">") 57 | // .replace(//g, "") 58 | // .replace(//g, "") 59 | // .replace(//g, "") 60 | // .replace(//g, "") 61 | // .replace(//g, "") 62 | // .replace(//g, "") 63 | // .replace(/<\/w:p>/g, "
") 64 | // .replace(//g, "
") 65 | // .replace(/<\/w:r>/g, "") 66 | // .replace(//g, "") 67 | // .replace(/<\/w:rPr>/g, "") 68 | // .replace(//g, "") 69 | // .replace(/<\/w:pPr>/g, "") 70 | // .replace(//g, "") 71 | // .replace(//g, "") 72 | // .replace(//g, "") 73 | // .replace(//g, "") 74 | // .replace(/<\/*w:.*?>/g, "") 75 | 76 | 77 | 78 | etree = et.parse(entry).findall('*')[0] 79 | // var tags = entry.split(/><|<|>/); 80 | // var text = entry.split(/>[^>|<]*<|<|>/)); 102 | }); 103 | 104 | getBody("./nom.docx", function(data, err) { 105 | if (err) console.log(err); 106 | else fs.writeFileSync('out.html', data) 107 | });//.split(/><|<|>/)); 108 | 109 | 110 | // >[^>|<]*< 111 | // /<[^<|>]*>/ 112 | // /><|<|>/ 113 | 114 | // getBody("./nom.docx", function(data, err) { 115 | // if (err) console.log(err) 116 | // else console.dir(traverseTree(data)); 117 | // }); -------------------------------------------------------------------------------- /nom_substructure/word/theme/theme1.xml: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /nom_substructure/word/numbering.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | 349 | 350 | 351 | -------------------------------------------------------------------------------- /out.html: -------------------------------------------------------------------------------- 1 |
What is the goal?
Minimize the cost of running a business using an IaaS/cloud platform by automatically allocating and deallocating cloud server instances to and from a cloud server network as the ratio of resource capacity vs resource demand fluctuates compared to a calculated/configurable threshold.
Field
The invention is generally directed toward cloud server network monitoring and management systems, and more particularly, allocating and deallocating cloud server instances to and from a cloud server network according to a cloud server balancing and consolidation algorithm which continuously monitors the loads on the cloud servers and deploys or releases cloud server instances according to the distribution of workload on server resources across a cloud server network.
Background
Conventional load balancers in computer systems “balance the load on a plurality of servers using a load balancing algorithm which continuously examines the loads on the plurality of servers and makes adjustments in the loads accordingly. Among the factors considered in the load balancing are the power of each server relative to other servers, the load on each server relative to the other servers, and a ‘credit’ for each server based on their power and load.”
Conventional load balancing, as defined in the preceding, is helpful when applied to an internal server network, but companies that host their server instances with a cloud service provider are introduced to a new load balancing problem that conventional load balancers cannot address.
“Cloud service providers offer programs, such as infrastructure as a service (IaaS), which use different pricing schemes when charging for use of cloud resources.” While a conventional load balancer may help ensure a company’s cloud server instances operate efficiently in a cloud server network, especially during times of peak usage, a conventional load balancer cannot minimize the cost of using a cloud server network because it balances the load among the cloud servers rather than assessing whether a new cloud server instance should be allocated or an old one deallocated.
Comparable to the way conventional load balancers allocate or deallocate resource demand to or from a server instance, this cloud server network management system allocates and deallocates cloud server instances from the cloud server network. However, resource demand must be allocated differently in this scenario to accommodate efficient allocation and deallocation of cloud server instances.
Allocation and deallocation of resource demand, for example, could be completed using strategies similar to those found in the patents below:
bin packing
https://www.google.com/patents/US20130235416
“Cloud computing services, such as production services, offer customers many benefits including reduced capital expenditures, scalability, managed upgrades and access to new workflows. Often, Infrastructure-as-a-Service cloud systems rent the use of virtual machines by the hour. Production jobs typically have an associated deadline by which the production job needs to be completed. Accordingly, it is important to schedule production jobs efficiently in order to maximize the use of a virtual machine during a rental period and therefore minimize the production cost.”
scheduler
https://www.google.com/patents/US8429659
(this patent is also really good for teminology)
a method for prioritizing jobs within a cloud computing environment, comprising: determining a processing capacity of the cloud computing environment; determining an income, a processing need, a set of service level agreement (SLA) terms for each of a plurality of jobs; and prioritizing the plurality of jobs based on their respective income, processing need, and SLA terms, wherein the prioritizing ensures that the set of SLA terms are met while maximizing the income and without exceeding the processing capacity.
NOTE: This patent app, written in Chinese, is very similar to this patent https://www.google.com/patents/CN102495759A
Because resource demand often changes, over or under utilization of these resources can be an issue. For example, as a cloud server instance process progresses, resource demand may decrease with the amount of tasks it has left to process. Conversely, resource demand may increase as new tasks are requested. Because conventional systems do not dynamically adapt to changing resource requirements, cumbersome manual intervention may be required to allocate new cloud server instances and increase capacity, or deallocate assigned cloud server instances and reclaim unused resources.
The pdf diagram shows a high level flowchart of how this idea will work, but processes will need to be described at the server level too.
Schedule tasks/resource demand/workload
I don’t think I need to describe this too thoroughly, but I will note that it is very important that tasks be assigned to cloud server instances in such a way that each cloud server instance has minimum surplus resources.
Although tasks can be assigned in such a way that each cloud server instance has minimum surplus resources, tasks will be completed at different rates and servers will inevitably be left with disparate amounts of surplus resources ranging from 0% to 100%.
continuously calculate distribution of tasks/resource demand/workload
Since the cloud server instances will inevitably have different resource demands on them as processes progress, it will be necessary to continuously monitor each server instance to make sure they are operating at maximum capacity.
consolidate resource demand when possible
If cloud server instances are found to not be fully utilized, then measures must be taken to maximize resource demand on cloud server instances. This will usually mean moving tasks from an under-utilized cloud server instance to a cloud server instance that has more tasks to process. However, by moving tasks away from the cloud server instance, the cloud server instance is even more underutilized. When this happens, the system must determine if it is cost-effective to deallocate the underutilized cloud server instance. If it is cost-effective, then the cloud server instance needs to be configured to refuse all future tasks from the cloud scheduler (this is the first time I’ve used this term, I should probably go back and give the scheduling step a name for a part of the system) so it can be deallocated without the risk of negatively impacting the processing of tasks in the cloud server network.
It is important to note that it may not always be feasible to deallocate a cloud server instance, even when it’s underutilized. For example, tracking historical peak demand for a company’s cloud network may reveal that resource demand will likely increase before the end of the hour. If this is the case, then it may be more cost-effective to extend the contract to run the cloud server instance instead of deallocating it because allocating another cloud server instance to meet the future increased resource demand will cost more money than would be saved by deallocating the underutilized server.
This system will take these scenarios into account as it manages the cloud server network. In the case described above, the system may need to take into account the pending increase in resource demand and stop consolidating resource demand on the cloud server network in order to more efficiently process jobs. That way the underutilized cloud server instance can still process tasks.
When there are surplus computing resources in the cloud server network
If there are surplus resources, then the system should calculate the cost of deallocating as cloud server instance. Depending on the resource cost and savings associated with deallocatng a cloud server instance, the system may or may not deallocate the cloud server instance. There are a lot of factors to take into account:
Time needed to deallocate a cloud server instance
Time needed to allocate a new cloud server instance when one is needed
Cost of deallocating a cloud server instance
if a cloud server instance is bid to run for 8 hours and has only ran for 6 hours, how much money is lost?
if a cloud server instance is deallocated, how many jobs will not be processed during the cloud server instance’s contract that otherwise could have
Cost of allocating a new cloud server instance
Bidding for new cloud server instances costs money
If the underutilized cloud server instance is not deallocated, then the system will continue monitoring and consolidating resource demand as cost-effectively as possible.
How to achieve this?
Calculate resource demand on each cloud server instance
Keep track of resource demand history
Calculate
Calculate Allocation/De-allocation of Cloud Server Instance
Can I use this? http://technet.microsoft.com/en-us/library/cc181325.aspx
We will have functions called:
double getServerLoadCapacity()
double getServerLoad()
double getServerLoad
-------------------------------------------------------------------------------- /nom.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Patent process.docx 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 53 | 54 | 55 |
56 | What is the goal? 57 |
58 |
59 |
60 |
61 | 1.Minimize the cost of running a business using an IaaS/cloud platform by automatically allocating and deallocating cloud server instances to and from a cloud server network as the ratio of resource capacity vs resource demand fluctuates compared to a calculated/configurable threshold. 62 |
63 |
64 |
65 |

66 |
Field 67 |
68 |
The invention is generally directed toward cloud server network monitoring and management systems, and more particularly, allocating and deallocating cloud server instances to and from a cloud server network according to a cloud server balancing and consolidation algorithm which continuously monitors the loads on the cloud servers and deploys or releases cloud server instances according to the distribution of workload on server resources across a cloud server network. 69 |
70 |

71 |
Background 72 |
73 |
Conventional load balancers in computer systems “balance the load on a plurality of servers using a load balancing algorithm which continuously examines the loads on the plurality of servers and makes adjustments in the loads accordingly. Among the factors considered in the load balancing are the power of each server relative to other servers, the load on each server relative to the other servers, and a ‘credit’ for each server based on their power and load.”
74 |
75 |
Conventional load balancing, as defined in the preceding, is helpful when applied to an internal server network, but companies that host their server instances with a cloud service provider are introduced to a new load balancing problem that conventional load balancers cannot address.
76 |
77 |
“Cloud service providers offer programs, such as infrastructure as a service (IaaS), which use different pricing schemes when charging for use of cloud resources.” While a conventional load balancer may help ensure a company’s cloud server instances operate efficiently in a cloud server network, especially during times of peak usage, a conventional load balancer cannot minimize the cost of using a cloud server network because it balances the load among the cloud servers rather than assessing whether a new cloud server instance should be allocated or an old one deallocated.
78 |
79 |
Comparable to the way conventional load balancers allocate or deallocate resource demand to or from a server instance, this cloud server network management system allocates and deallocates cloud server instances from the cloud server network. However, resource demand must be allocated differently in this scenario to accommodate efficient allocation and deallocation of cloud server instances.
80 |

81 |
Allocation and deallocation of resource demand, for example, could be completed using strategies similar to those found in the patents below:
82 |

83 |
bin packing
84 |
https://www.google.com/patents/US20130235416
85 |
“Cloud computing services, such as production services, offer customers many benefits including reduced capital expenditures, scalability, managed upgrades and access to new workflows. Often, Infrastructure-as-a-Service cloud systems rent the use of virtual machines by the hour. Production jobs typically have an associated deadline by which the production job needs to be completed. Accordingly, it is important to schedule production jobs efficiently in order to maximize the use of a virtual machine during a rental period and therefore minimize the production cost.”
86 |

87 |
scheduler
88 |
https://www.google.com/patents/US8429659
89 |
(this patent is also really good for teminology)
90 |
a method for prioritizing jobs within a cloud computing environment, comprising: determining a processing capacity of the cloud computing environment; determining an income, a processing need, a set of service level agreement (SLA) terms for each of a plurality of jobs; and prioritizing the plurality of jobs based on their respective income, processing need, and SLA terms, wherein the prioritizing ensures that the set of SLA terms are met while maximizing the income and without exceeding the processing capacity.
91 |

92 |
NOTE: This patent app, written in Chinese, is very similar to this patent https://www.google.com/patents/CN102495759A
93 |

94 |
Because resource demand often changes, over or under utilization of these resources can be an issue. For example, as a cloud server instance process progresses, resource demand may decrease with the amount of tasks it has left to process. Conversely, resource demand may increase as new tasks are requested. Because conventional systems do not dynamically adapt to changing resource requirements, cumbersome manual intervention may be required to allocate new cloud server instances and increase capacity, or deallocate assigned cloud server instances and reclaim unused resources.
95 |

96 |
The pdf diagram shows a high level flowchart of how this idea will work, but processes will need to be described at the server level too.
97 |

98 |
Schedule tasks/resource demand/workload
99 |
I don’t think I need to describe this too thoroughly, but I will note that it is very important that tasks be assigned to cloud server instances in such a way that each cloud server instance has minimum surplus resources.
100 |
Although tasks can be assigned in such a way that each cloud server instance has minimum surplus resources, tasks will be completed at different rates and servers will inevitably be left with disparate amounts of surplus resources ranging from 0% to 100%.
101 |

102 |
continuously calculate distribution of tasks/resource demand/workload
Since the cloud server instances will inevitably have different resource demands on them as processes progress, it will be necessary to continuously monitor each server instance to make sure they are operating at maximum capacity.
103 |

104 |
consolidate resource demand when possible
105 |
If cloud server instances are found to not be fully utilized, then measures must be taken to maximize resource demand on cloud server instances. This will usually mean moving tasks from an under-utilized cloud server instance to a cloud server instance that has more tasks to process. However, by moving tasks away from the cloud server instance, the cloud server instance is even more underutilized. When this happens, the system must determine if it is cost-effective to deallocate the underutilized cloud server instance. If it is cost-effective, then the cloud server instance needs to be configured to refuse all future tasks from the cloud scheduler (this is the first time I’ve used this term, I should probably go back and give the scheduling step a name for a part of the system) so it can be deallocated without the risk of negatively impacting the processing of tasks in the cloud server network.
106 |

107 |
It is important to note that it may not always be feasible to deallocate a cloud server instance, even when it’s underutilized. For example, tracking historical peak demand for a company’s cloud network may reveal that resource demand will likely increase before the end of the hour. If this is the case, then it may be more cost-effective to extend the contract to run the cloud server instance instead of deallocating it because allocating another cloud server instance to meet the future increased resource demand will cost more money than would be saved by deallocating the underutilized server.
108 |

109 |
This system will take these scenarios into account as it manages the cloud server network. In the case described above, the system may need to take into account the pending increase in resource demand and stop consolidating resource demand on the cloud server network in order to more efficiently process jobs. That way the underutilized cloud server instance can still process tasks.
110 |

111 |
When there are surplus computing resources in the cloud server network
112 |
If there are surplus resources, then the system should calculate the cost of deallocating as cloud server instance. Depending on the resource cost and savings associated with deallocatng a cloud server instance, the system may or may not deallocate the cloud server instance. There are a lot of factors to take into account:
113 |
114 |
115 |
1.Time needed to deallocate a cloud server instance
116 |
117 |
118 |
2.Time needed to allocate a new cloud server instance when one is needed
119 |
120 |
3.Cost of deallocating a cloud server instance
121 |
122 |
123 |
a.if a cloud server instance is bid to run for 8 hours and has only ran for 6 hours, how much money is lost?
124 |
125 |
b.if a cloud server instance is deallocated, how many jobs will not be processed during the cloud server instance’s contract that otherwise could have
126 |
127 |
128 |
129 |
130 |
4.Cost of allocating a new cloud server instance
131 |
132 |
133 |
a.Bidding for new cloud server instances costs money
134 |
135 |
136 |
137 |

138 |
If the underutilized cloud server instance is not deallocated, then the system will continue monitoring and consolidating resource demand as cost-effectively as possible.
139 |

140 |

141 |

142 |

143 |
144 |
145 |

146 |
How to achieve this?
147 |
148 |
1.Calculate resource demand on each cloud server instance
149 |
150 |
151 |
a.
152 |
153 |
154 |
155 |
156 |
2.Keep track of resource demand history 157 |
158 |
159 |
160 |
3.Calculate
161 |
162 |
163 |

164 |
Calculate Allocation/De-allocation of Cloud Server Instance
165 |
Can I use this? http://technet.microsoft.com/en-us/library/cc181325.aspx
166 |

167 |
We will have functions called:
double getServerLoadCapacity()
double getServerLoad()
double getServerLoad 168 |
169 | 170 | -------------------------------------------------------------------------------- /nom_substructure/word/styles.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | 392 | 393 | 394 | 395 | 396 | 397 | 398 | 399 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | 449 | 450 | 451 | 452 | 453 | 454 | 455 | 456 | 457 | 458 | 459 | 460 | 461 | 462 | 463 | 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | 479 | 480 | 481 | 482 | 483 | 484 | 485 | 486 | 487 | 488 | 489 | 490 | 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | 502 | 503 | 504 | 505 | 506 | 507 | 508 | 509 | 510 | 511 | 512 | 513 | 514 | 515 | 516 | 517 | 518 | 519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 | 529 | 530 | 531 | 532 | 533 | 534 | 535 | 536 | 537 | 538 | 539 | 540 | 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | 555 | -------------------------------------------------------------------------------- /nom_substructure/word/document.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | What is the goal? 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | Minimize the cost 31 | 32 | 33 | of running a business using an 34 | 35 | 36 | 37 | 38 | 39 | 40 | IaaS 41 | 42 | 43 | 44 | 45 | 46 | 47 | /cloud platform 48 | 49 | 50 | by automatically allocating and 51 | 52 | 53 | 54 | 55 | 56 | 57 | deallocating 58 | 59 | 60 | 61 | 62 | 63 | 64 | cloud server instances 65 | 66 | 67 | to and from a cloud server network as the ratio of 68 | 69 | 70 | 71 | 72 | 73 | resource capacity 74 | 75 | 76 | vs 77 | 78 | 79 | 80 | 81 | 82 | resource demand 83 | 84 | 85 | fluctuates compared to a calculated/configurable 86 | 87 | 88 | 89 | 90 | 91 | threshold. 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | Field 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | The invention is generally directed toward cloud server network monitoring and management systems, and more 119 | 120 | 121 | 122 | 123 | 124 | particularly, allocating 125 | 126 | 127 | and 128 | 129 | 130 | 131 | deallocating 132 | 133 | 134 | 135 | cloud server instances to and from a cloud server network according to a cloud server balancing and consolidation algorithm which 136 | 137 | 138 | 139 | 140 | 141 | continuously 142 | 143 | 144 | monitors the loads on the cloud 145 | 146 | 147 | 148 | 149 | 150 | servers 151 | 152 | 153 | and deploys or 154 | 155 | 156 | 157 | 158 | 159 | 160 | releases 161 | 162 | 163 | cloud server instances according to the distribution of workload on server resources across a cloud server 164 | 165 | 166 | 167 | network. 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | Background 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | Conventional 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | load balancers 199 | 200 | 201 | 202 | in computer systems “balance the load on a plurality of servers using a load balancing algorithm which continuously examines the loads on the plurality of 203 | 204 | 205 | 206 | servers 207 | 208 | 209 | 210 | and makes adjustments in the loads accordingly. Among the factors considered in the load balancing are the power of each server relative to other servers, the load on each server relative to the other servers, and a ‘credit’ for each server based on their power and load.” 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | Conventional load balancing, as defined in the preceding, is helpful when applied to an internal server network, but companies that host their server instances with a cloud service provider are introduced to a new load balancing problem that conventional load balancers cannot address. 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | “ 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | Cloud service providers offer programs 245 | 246 | 247 | 248 | , such as infrastructure as a service ( 249 | 250 | 251 | 252 | IaaS 253 | 254 | 255 | 256 | ), which use different pricing schemes when charging for use of cloud resources.” While a conventional load balancer may help ensure a company’s cloud server instances operate efficiently in a cloud 257 | 258 | 259 | 260 | server network, especially during times of peak usage, a conventional load balancer cannot minimize the cost of using a cloud server network because it balances the load among the cloud servers rather than assessing whether a new cloud server instance should be allocated or an old one 261 | 262 | 263 | 264 | deallocated 265 | 266 | 267 | 268 | . 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | Comparable to the way conventional load balancers allocate or 285 | 286 | 287 | 288 | 289 | 290 | 291 | deallocate 292 | 293 | 294 | 295 | 296 | 297 | 298 | resource demand to or from a server instance, this cloud server network management system allocates and 299 | 300 | 301 | 302 | 303 | 304 | 305 | deallocates 306 | 307 | 308 | 309 | 310 | 311 | 312 | cloud server instances from the cloud server network 313 | 314 | 315 | . However, resource demand must be allocated differently in this scenario to accommodate efficient allocation and 316 | 317 | 318 | 319 | deallocation 320 | 321 | 322 | 323 | of cloud server instances. 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | Allocation and 337 | 338 | 339 | 340 | deallocation 341 | 342 | 343 | 344 | of resource demand, for example, could be completed using strategies similar to those found in the patents below: 345 | 346 | 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | bin 365 | 366 | 367 | 368 | 369 | 370 | 371 | packing 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | https://www.google.com/patents/US20130235416 386 | 387 | 388 | 389 | 390 | 391 | 392 | 393 | 394 | 395 | 396 | 397 | 398 | 399 | 400 | “Cloud computing services, such as production services, offer customers many benefits including reduced capital expenditures, scalability, managed upgrades and access to new workflows. Often, Infrastructure-as-a-Service cloud systems rent the use of virtual machines by the hour. Production jobs typically have an associated deadline by which the production job needs to be completed. Accordingly, it is important to schedule production jobs efficiently in order to maximize the use of a virtual machine during a rental period and therefore minimize the production cost.” 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | scheduler 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | https://www.google.com/patents/US8429659 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | ( 448 | 449 | 450 | 451 | this 452 | 453 | 454 | 455 | patent is also really good for 456 | 457 | 458 | 459 | teminology 460 | 461 | 462 | 463 | ) 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | a method for prioritizing jobs within a 478 | 479 | 480 | 481 | 482 | 483 | 484 | 485 | cloud 486 | 487 | 488 | 489 | 490 | 491 | 492 | 493 | computing environment, comprising: determining a processing capacity of the 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | cloud 502 | 503 | 504 | 505 | 506 | 507 | 508 | 509 | computing environment; determining an income, a processing need, a set of service level agreement (SLA) terms for each of a plurality of jobs; and prioritizing the plurality of jobs based on their respective income, processing need, and SLA terms, wherein the prioritizing ensures that the set of SLA terms are met while maximizing the income and without exceeding the processing capacity. 510 | 511 | 512 | 513 | 514 | 515 | 516 | 517 | 518 | 519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | NOTE: This patent app, written in Chinese, is very similar to this patent 528 | 529 | 530 | 531 | 532 | 533 | 534 | 535 | https://www.google.com/patents/CN102495759A 536 | 537 | 538 | 539 | 540 | 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | Because 555 | 556 | 557 | 558 | resource demand often changes, over or under utilization of these resources can be an issue. For example, as a cloud server instance process progresses, resource demand may decrease with the amount of tasks it has left to process. Conversely, resource demand may 559 | 560 | 561 | 562 | increase as new tasks are requested. Because conventional systems do not dynamically adapt to changing resource requirements, cumbersome manual intervention may be required to allocate new cloud server instances and increase capacity, or 563 | 564 | 565 | 566 | deallocate 567 | 568 | 569 | 570 | assigned cloud server instances and reclaim unused resources. 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | The pdf diagram shows a high level flowchart of how this idea will work, but processes will need to be described at the server level too. 584 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 | 595 | 596 | 597 | 598 | 599 | Schedule tasks/resource demand/workload 600 | 601 | 602 | 603 | 604 | 605 | 606 | 607 | I don’t think I need to describe this too thoroughly, but I will note that it is very important that tasks be assigned to cloud server instances in such a way that each cloud server instance has minimum surplus resources. 608 | 609 | 610 | 611 | 612 | 613 | 614 | 615 | Although tasks can be assigned in such a way that each cloud server instance has minimum surplus resources, tasks will be completed at different rates and servers will inevitably be left with disparate amounts of surplus resources ranging from 0% to 100%. 616 | 617 | 618 | 619 | 620 | 621 | 622 | 623 | 624 | 625 | 626 | 627 | 628 | 629 | 630 | 631 | 632 | continuously 633 | 634 | 635 | 636 | 637 | 638 | 639 | calculate distribution of tasks/resource demand/workload 640 | 641 | 642 | 643 | 644 | 645 | 646 | 647 | Since the cloud server instances will inevitably have different resource demands on them as processes progress, it will be necessary to continuously monitor each server instance to make sure they are operating at maximum capacity. 648 | 649 | 650 | 651 | 652 | 653 | 654 | 655 | 656 | 657 | 658 | 659 | 660 | 661 | 662 | 663 | 664 | consolidate 665 | 666 | 667 | 668 | 669 | 670 | 671 | resource demand when possible 672 | 673 | 674 | 675 | 676 | 677 | 678 | 679 | If cloud server instances are found to not be fully utilized, then measures must be taken to maximize resource demand on cloud server instances. This will usually mean moving tasks from an under-utilized cloud server instance to a cloud server instance that has more tasks to process. However, by moving tasks away from the cloud server instance, the cloud server instance is even more underutilized. When this happens, the system must determine if it is cost-effective to 680 | 681 | 682 | 683 | deallocate 684 | 685 | 686 | 687 | the underutilized cloud server instance. If it is cost-effective, then the cloud server instance needs to be configured to refuse all future tasks from the cloud scheduler (this is the first time I’ve used this term, I should probably go back and give the scheduling step a name for a part of the system) so it can be 688 | 689 | 690 | 691 | deallocated 692 | 693 | 694 | 695 | without the risk of negatively impacting the processing of tasks in the cloud server network. 696 | 697 | 698 | 699 | 700 | 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | 709 | It is important to note that it may not always be feasible to 710 | 711 | 712 | 713 | deallocate 714 | 715 | 716 | 717 | a cloud server instance, even when it’s underutilized. For example, tracking historical peak demand for a company’s cloud network may reveal that resource demand will likely increase before the end of the hour. If this is the case, then it may be more cost-effective to extend the contract to run the cloud server instance instead of 718 | 719 | 720 | 721 | deallocating 722 | 723 | 724 | 725 | it because allocating another cloud server instance to meet the future increased resource demand will cost more money than would be saved by 726 | 727 | 728 | 729 | deallocating 730 | 731 | 732 | 733 | the underutilized server. 734 | 735 | 736 | 737 | 738 | 739 | 740 | 741 | 742 | 743 | 744 | 745 | 746 | This system will take these scenarios into account as it manages the cloud server network. In the case described above, the system may need to take into account the pending increase in resource demand and stop consolidating resource demand on the cloud server network in order to more efficiently process jobs. That way the underutilized cloud server instance can still process tasks. 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | When there are surplus computing resources in the cloud server network 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | If there are surplus resources, then the system should calculate the cost of 771 | 772 | 773 | 774 | deallocating 775 | 776 | 777 | 778 | as cloud server instance. Depending on the resource cost and savings associated with 779 | 780 | 781 | 782 | deallocatng 783 | 784 | 785 | 786 | a cloud server instance, the system may or may not 787 | 788 | 789 | 790 | deallocate 791 | 792 | 793 | 794 | the cloud server instance. There are a lot of factors to take into account: 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | 803 | 804 | 805 | 806 | 807 | 808 | Time needed to 809 | 810 | 811 | 812 | deallocate 813 | 814 | 815 | 816 | a cloud server instance 817 | 818 | 819 | 820 | 821 | 822 | 823 | 824 | 825 | 826 | 827 | 828 | 829 | 830 | Time needed to allocate a new cloud server instance when one is needed 831 | 832 | 833 | 834 | 835 | 836 | 837 | 838 | 839 | 840 | 841 | 842 | 843 | 844 | Cost of 845 | 846 | 847 | 848 | deallocating 849 | 850 | 851 | 852 | a cloud server instance 853 | 854 | 855 | 856 | 857 | 858 | 859 | 860 | 861 | 862 | 863 | 864 | 865 | 866 | 867 | if 868 | 869 | 870 | 871 | a 872 | 873 | 874 | cloud server instance is bid 875 | 876 | 877 | to run for 8 hours and has only ran for 6 hours, how much money is lost? 878 | 879 | 880 | 881 | 882 | 883 | 884 | 885 | 886 | 887 | 888 | 889 | 890 | 891 | if a cloud server instance is 892 | 893 | 894 | 895 | deallocated 896 | 897 | 898 | 899 | , how many jobs will not be processed during the cloud server instance’s contract that otherwise could have 900 | 901 | 902 | 903 | 904 | 905 | 906 | 907 | 908 | 909 | 910 | 911 | 912 | 913 | Cost of allocating a new cloud server instance 914 | 915 | 916 | 917 | 918 | 919 | 920 | 921 | 922 | 923 | 924 | 925 | 926 | 927 | Bidding for new cloud server instances costs money 928 | 929 | 930 | 931 | 932 | 933 | 934 | 935 | 936 | 937 | 938 | 939 | 940 | If the underutilized cloud server instance is not 941 | 942 | 943 | 944 | deallocated 945 | 946 | 947 | 948 | , then the system will continue monitoring and consolidating resource demand as cost-effectively as possible. 949 | 950 | 951 | 952 | 953 | 954 | 955 | 956 | 957 | 958 | 959 | 960 | 961 | 962 | 963 | 964 | 965 | 966 | 967 | 968 | 969 | 970 | 971 | 972 | 973 | 974 | 975 | 976 | 977 | 978 | How to achieve this? 979 | 980 | 981 | 982 | 983 | 984 | 985 | 986 | 987 | 988 | 989 | 990 | 991 | Calculate resource demand on each cloud server instance 992 | 993 | 994 | 995 | 996 | 997 | 998 | 999 | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 | 1009 | 1010 | 1011 | 1012 | 1013 | 1014 | Keep track of resource demand history 1015 | 1016 | 1017 | 1018 | 1019 | 1020 | 1021 | 1022 | 1023 | 1024 | 1025 | 1026 | 1027 | Calculate 1028 | 1029 | 1030 | 1031 | 1032 | 1033 | 1034 | 1035 | 1036 | 1037 | 1038 | 1039 | 1040 | 1041 | 1042 | 1043 | 1044 | 1045 | 1046 | Calculate Allocation/De 1047 | 1048 | 1049 | 1050 | 1051 | 1052 | - 1053 | 1054 | 1055 | 1056 | 1057 | 1058 | allocation of Cloud Server Instance 1059 | 1060 | 1061 | 1062 | 1063 | 1064 | 1065 | 1066 | Can I use this? 1067 | 1068 | 1069 | 1070 | 1071 | 1072 | 1073 | http://technet.microsoft.com/en-us/library/cc181325.aspx 1074 | 1075 | 1076 | 1077 | 1078 | 1079 | 1080 | 1081 | 1082 | 1083 | 1084 | 1085 | 1086 | 1087 | We will have functions called 1088 | 1089 | 1090 | 1091 | : 1092 | 1093 | 1094 | 1095 | 1096 | double 1097 | 1098 | 1099 | 1100 | getServerLoadCapacity 1101 | 1102 | 1103 | 1104 | () 1105 | 1106 | 1107 | 1108 | double 1109 | 1110 | 1111 | 1112 | getServerLoad 1113 | 1114 | 1115 | 1116 | () 1117 | 1118 | 1119 | 1120 | double 1121 | 1122 | 1123 | 1124 | getServerLoad 1125 | 1126 | 1127 | 1128 | 1129 | 1130 | 1131 | 1132 | 1133 | 1134 | --------------------------------------------------------------------------------