Distributed Computing and Distributed Systems: History, Management and Fallacies

Lecture



Distributed computing — a way of solving computationally intensive problems using several computers, most often joined together into a parallel computing system. Distributed computing is also applicable in distributed control systems.

Sequential computations in distributed systems are performed with allowance for the simultaneous solving of many tasks. A distinguishing feature of distributed multiprocessor computing systems, as opposed to local supercomputers, is the ability to increase performance without limit through scaling. :550 Loosely coupled, heterogeneous computing systems with a high degree of distribution are singled out into a separate class of distributed systems — the grid.

One should distinguish distributed computing from parallel and decentralized computing.

Parallel computing — a way of organizing computer computations in which programs are developed as a set of interacting computational processes running in parallel (simultaneously). The term covers the whole range of parallelism issues in programming, as well as the creation of efficiently operating hardware implementations. The theory of parallel computing constitutes a branch of applied algorithm theory .

There are various ways of implementing parallel computing. For example, each computational process can be implemented as an operating-system process, or the computational processes can be a set of threads of execution within a single OS process. Parallel programs can physically execute either sequentially on a single processor — interleaving in turn the execution steps of each computational process — or in parallel — allocating one or more processors to each computational process (located nearby or distributed over a computer network).

The main difficulty in designing parallel programs is ensuring the correct sequence of interactions between the various computational processes, as well as coordinating the resources shared between processes.

Decentralized application (decentralized application, DApp, dApp, ) — a computer application, which is based on blockchain technology combined with a mechanism for distributed execution of the required instructions. As of 2021, the most commonly used for this is Ethereum with its smart-contract mechanism, but there are also variants on the Waves blockchain platform.

Distributed system — a system for which the relations between the locations of elements (or groups of elements) play a significant role from the point of view of the system's functioning, and consequently also from the point of view of analyzing and synthesizing the system.

Distributed systems are characterized by the distribution of functions and resources among a multitude of elements (nodes) and the absence of a single control center, so the failure of one of the nodes does not lead to a complete stop of the whole system. A typical distributed system is the Internet.

2. Modes of program execution

  • multitasking mode (time-sharing mode);
  • parallel execution;
  • distributed computing.

Distributed Computing and Distributed Systems: History, Management and Fallacies
(a), (b): distributed system.
(c): parallel system. Wikipedia site:tftwiki.ru

Examples of distributed systems

  • A distributed system of computers — a computer network.
  • A distributed control system — a technological process control system.
  • Distributed power generation
  • Distributed economy
  • A distributed file system — network file systems.
  • Distributed operating systems
  • Distributed computing systems
  • Distributed version control systems
  • Distributed databases
    • The Domain Name System (DNS) — a distributed system for obtaining information about domains.

History of parallel and distributed computing

Work on distributed computing for a very applied purpose — for military needs, namely the automation of secret-communication processes and the processing of intelligence information — was carried out intensively in the USA starting in the 1960s. The development of distributed computing technologies and the creation of distributed information systems in the United States, commissioned by the Defense Advanced Research Projects Agency, the branches of the armed forces and services (agencies) within the structure of the US Department of Defense, was handled by the research divisions of companies and universities:

  • Bolt, Beranek and Newman, Cambridge, Massachusetts;
  • Computer Corporation of America, Cambridge, Massachusetts;
  • Network Analysis Corporation, Glen Cove, Long Island;
  • System Development Corporation, Santa Monica, California;
  • Stanford Research Institute, Menlo Park, California;
  • National Institute of Standards and Technology, Washington, D.C.;
  • University of California, Los Angeles, California;
  • Defense Communications Agency, Scott, Illinois.

Distributed Computing and Distributed Systems: History, Management and Fallacies

As part of the fundamental research, R&D and design work being carried out, corresponding hardware-software complexes were developed for already-existing low-level (machine-oriented) programming languages, along with special software with cryptographic protection, etc.

In 1973, John Shoch and Jon Hupp of the Xerox PARC research center in California wrote a program that ran into the PARC local network at night and made the working computers perform computations .

In 1977, at NETI (NSTU, Novosibirsk), at the Department of Computer Engineering under the direction of V. I. Zhiratkov, a distributed computing system of three “Minsk-32” computers was developed with original hardware and software supporting physical, data-link and network layer protocols and providing for the execution of parallel tasks. One machine was located at the NSTU Computing Center, and the other two — at the Computing Center of the Institute of Mathematics of the Siberian Branch of the USSR Academy of Sciences. Communication between NSTU and the Institute of Mathematics was provided over a radio channel using directional antennas. The system was tested by solving optimization problems in economics using coarse-grained parallelization.

In 1978, the Soviet mathematician Viktor Glushkov worked on the problem of macropipeline distributed computing. He proposed a number of principles for distributing work among processors. :320 Based on these principles, he developed the EC-2701 computer.

In 1988, Arjen Lenstra and Mark Manasse wrote a program for factoring large numbers. To speed up the process, the program could be run on several machines, each of which processed its own small fragment. .

In 1994, David Gedye proposed the idea of organizing a mass distributed computing project that would use the computers of volunteers (so-called volunteer computing) — SETI@Home . The project's scientific plan, developed by David Gedye and Craig Kasnoff of Seattle, was presented at the fifth international conference on bioastronomy in July 1996 .

In January 1996, the GIMPS project for finding Mersenne prime numbers started, also using the computers of ordinary users as a volunteer computing network.

On January 28, 1997, the RSA Data Security contest started, aimed at solving the problem of breaking a 56-bit RC5 encryption key by brute force. Thanks to good technical and organizational preparation, the project, organized by the nonprofit community distributed.net, quickly gained wide recognition .

On May 17, 1999, SETI@home started on a Grid basis, and at the beginning of 2002 the University of California, Berkeley completed development of the open BOINC platform (Berkeley Open Infrastructure for Network Computing), which had been under development since April 2000, originally for SETI@Home, though the first project on the BOINC platform was Predictor@home, launched on June 9, 2004.

As cloud services reached today's level, in order to ensure more efficient use of distributed architecture and further reduce delays on the client side, the structure of fog computing was created, and even, with the aim of including client devices in the cloud, the structure of dew computing.

Distributed Computing and Distributed Systems: History, Management and Fallacies

Types of cloud technologies

Many of the applications we use today benefit from the use of cloud services. However, the level of use of these cloud technology services, or in other words the speed of access to the cloud, can vary. Cloud services are usually divided into three main groups according to this ratio. These classifications are often commensurate with the distribution of responsibility.

Distributed Computing and Distributed Systems: History, Management and Fallacies

Hierarchy and requirements of distributed computing


So, there is a new hierarchical structure consisting of three levels: cloud, fog and dew computing. These hierarchical layers are designed to facilitate rapidly evolving complex distributed computer systems and must meet the following requirements:

  • Performance: optimized for fast response, low-latency processing;
  • Availability: require redundancy, fast recovery in the event of system failures;
  • Reliability: the system must be reliable in terms of data and functioning;
  • Manageability: a scalable system that must be simple to operate;
  • Cost: includes hardware and software costs, but it is also important to take into account other aspects necessary for deploying and supporting a scalable computing system.

Management of computing jobs

The problem of distributing various computing tasks within a distributed system belongs to the problem of decision-making under uncertainty. This problem is examined in decision theory and in uncertainty theory.

Distributed operating systems

A distributed OS, by dynamically and automatically distributing jobs among the various machines of the system for processing, makes a set of networked machines process information in parallel. A user of a distributed OS, generally speaking, has no information about which machine their job is running on.

A distributed OS exists as a single operating system across the scale of the computing system. Each computer on the network, operating under the control of the distributed OS, performs part of the functions of this global OS. A distributed OS unites all the computers of the network in the sense that they work in close cooperation with each other for the efficient use of all the resources of the computer network.

As a result, a network OS can be viewed as a set of operating systems of the individual computers making up the network. Different computers on the network may run the same or different OSes. For example, all computers on the network may run the same UNIX OS. A more realistic option is a network in which different OSes run, for example, part of the computers run under UNIX, part — under NetWare, and the rest — under Windows NT and Windows 98. All these operating systems function independently of one another in the sense that each of them makes independent decisions about creating and terminating its own processes and managing local resources. But in any case, the operating systems of computers working on a network must include a mutually agreed set of communication protocols for organizing the interaction of processes running on different computers on the network, and for sharing the resources of these computers among the network's users.

If the operating system of an individual computer allows it to operate on a network, and can make its resources available for shared use and/or use the resources of other computers on the network, then such an operating system of an individual computer is also called a network OS.

Thus, the term “network operating system” is used in two senses: as the aggregate of the OSes of all computers on a network, and as the operating system of an individual computer capable of working on a network. From this definition it follows that operating systems such as, for example, Windows NT, NetWare, Solaris, HP-UX, are network OSes, since all of them have facilities that allow their users to work on a network.

Fallacies of distributed computing

The fallacies of distributed computing — are a set of assertions made by L. Peter Deutsch and others at Sun Microsystems describing false assumptions that programmers who are poorly acquainted with distributed applications invariably make.

Fallacies:

  1. The network is reliable;
  2. Latency is zero;
  3. Bandwidth is infinite;
  4. The network is secure;
  5. Topology doesn't change;
  6. There is one administrator;
  7. Transport cost is zero;
  8. The network is homogeneous.

Consequences of the fallacies

  • Service applications (services) are written with minimal handling of network errors. During a network failure, such services may hang or wait indefinitely for a response packet, continuously consuming memory or other resources. When the failed network becomes available again, services cannot resume the frozen/interrupted operations and require a restart.
  • Ignorance of network latency and the packet loss it can cause prompts application developers and transport-layer developers to allow unlimited traffic, significantly increasing the number of dropped packets and wasting bandwidth.
  • Ignorance of bandwidth limitations on the part of traffic senders can lead to the emergence of bottlenecks.
  • Overconfidence regarding network security leads to attackers becoming hard to distinguish in the process of constantly adapting new services to security measures.
  • Changes in network topology can affect both bandwidth and latency issues, and consequently services will experience similar problems.
  • Multiple administrators, as in the case of subnets belonging to competing companies, may set conflicting policies, which senders of network traffic must be aware of in order to complete the desired paths.
  • The “hidden” costs of creating and maintaining a network or subnet are not insignificant and consequently should be noted in budgets in order to avoid a significant shortfall.
  • If a system assumes a homogeneous network, this can lead to the same problems that arise from the first three fallacies.

History

The list of common fallacies originated at Sun Microsystems. L. Peter Deutsch, one of Sun's first “Fellows”, is credited [who?] with writing the first seven fallacies in 1994; however, Bill Joy and Tom Lyon had already identified the first four as the “Fallacies of Networked Computing” (the article mentions “Dave Lyon”, but this is an error [citation needed?]). Around 1997, James Gosling, another Sun employee and the inventor of Java, added the eighth fallacy.

See also

  • [[b5592]]
  • [[b5594]]
  • [[b5598]]
  • CAP theorem
  • PACELC theorem
  • cloud computing
  • fog computing
  • dew computing
  • Parallel computing
  • Grid
  • Cloud computing
  • Distributed database
  • Multithreading
  • Multitasking
  • Parallel computing systems
  • Classification of parallel computing systems
  • Amdahl's law
  • Macropipeline
  • Computing pipeline
  • Symmetric multiprocessing
  • Massively parallel architecture
  • Botnet
  • Client-server
  • Peer-to-peer networks
  • Cluster
  • MIPS

See also

Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "Highly loaded projects. Theory of parallel computing. Supercomputers. Distributed systems"

Terms: Highly loaded projects. Theory of parallel computing. Supercomputers. Distributed systems