Cluster computing

Saturday, December 12, 2020

This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html

Listings are great to use when they are in a single location. They are often scoped to a parent container. If the parent containers are distributed, the listings tend to be multiple. In such cases, the effort is repeated.

When the listings are separated by locations, the results from the search may be fewer than the expected total if only one of the locations is searched. This has often been encountered in deployments.

The listings do not need to be aggregated across locations in all cases. Sometimes, only the location is relevant, and the listing and the search can be scoped to it.

Iterating the listings has proved banal in most cases both for the system and for the user. Consequently, either an identifier is used to go directly to the entry in the listing, or a listing is reserved so that only that listing is accessed.

The listing can be cleaned up as well. There is no need to keep it growing with outdated entries and then archived by age. The cleaning can happen in the background so that list iterations skip over entries or do not see the entries that appear as removed.

Listing entry values are particularly interesting. In addition to the type of attributes in an entry, we can take advantage of the range of values that these attributes can take. For example, we can reserve boundary values and extremely tiny values that will not be encountered in the real world at least for most cases.

This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html

If the listing is common to several consumers, a key may be used for each consumer for their specific needs. If this approach does not scale, then the listing may be retrieved in ranges and the filtering may be taken over on the compute side.

The keys will need to have backward compatibility otherwise they break existing scenarios.

When a new key is added, it may not impact existing keys, but it does affect the overall space consumption of the listing depending on the size and number.

The keys can have as many fields as necessary. If this becomes slow, the lookups can be faster when there are only a few keys to compare.

Key comparison can be partial or full. Partial keys are useful to match duplicates. The number of keys that share the same subkeys can be many. This form of comparison is very helpful to group entries.

Grouping of entries also helps with entries that span groups based on subkeys. These work across groups

This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html

The results from the background tasks mentioned above might also take a long time to accumulate. They can be made available as they appear or batched.

The load balancer works very well to enable background tasks to catch up by not overloading a single task and distributing the online activities to ensure that the background task has light load

The number of background tasks or their type should not affect online activities. However, systems have known to be impacted when the tasks are consuming memory or delay garbage collection

If one or more background tasks takes plenty of shared resources, they can be canceled and they are written to be fault tolerant so that they can pick up from where they left off.

The use of lookup keys is common to find entries in listings. The key generally comprises of a prefix and one or more values pertaining to related entities.

The type and number of keys can change even in the same listing. They can also be used as markers

If the listing is common to several consumers, a key may be used for each consumer for their specific needs. If this approach does not scale, the listing may be retrieved in ranges and the filtering may be taken over on the compute side.

This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html

Networking, compute and storage are inter-dependent. We use data structures to keep the information we want to access in a convenient form. When this is persisted, it mitigates faults in the processing. Artifact brings in additional chores and maintenance while it is cheaper to execute the logic. Versioning of logic helps track the changes. When there is a trade-off between computing and storage for numerous small and cheap artifacts, it is better to generate them dynamically.

The above has a far-reaching impact when there are layers involved and the cost incurred in the lower layer bubbles up to the top layer.

Compute tends to be distributed in nature while storage tends to be local. They can be mutually exclusive in this regard.

Compute oriented processing can assign priority dynamically but storage tends to remain in a class

Background tasks may sometimes need to catch up with the current activities. In order to accommodate the delay, they may either be run upfront so that changes to be processed are incremental or they can increase in number to divide up the work.

This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html

There are very few cases where the system or the process goes wrong. On the other hand, there is a lot of advantage to trusting the process. It is better not to try to beat the system but to make it work for you.

As with any product, a networking product also qualifies for the Specific-measureable-attainable-realistic-timely aka SMART process where improvements can be measured and the feedback used to improve the process and the product.
Every process change comes with an onus and is probably the least favored by employees but the rewards generally outweigh the costs when it is reasoned and accepted by all. The six-sigma process for example sets a high bar for quality because it eliminates errors progressively.

The iterations for six-sigma were high so it takes a long time and the results are not always available in the interim. The agile development processes allowed results to be incremental.

The agile methodology improved the iterations over the features in such a way that it did not impact the rest of the product. This enables faster feature development

The continuous integration and continuous deployment model made the individual feature improvements available for use because the changes were build, tested and deployed in lock step with development.