Abstract: Methods of Electrical Discharge Machining (EDM) ceramic components are provided. In one aspect, a method includes electrical discharge machining a ceramic component, such as a Ceramic Matrix Composite (CMC) component. The ceramic component is electrical discharge machined while a contact matrix is positioned so that electrically conductive compliant and pressurized contacts of the contact matrix engage the ceramic component and so that an electrically conductive member of the contact matrix is in electrical conduction to a grounding structure.

Abstract: A system for forming features within composite components includes a tubular electrode extending along a longitudinal direction from a proximal end to a distal end. The distal end is, in turn, configured to be positioned relative to a machining surface of the composite component such that a spark gap is defined between the distal end and the machining surface. Furthermore, the tubular electrode further extends in a radial direction between an inner surface and an outer surface, with the inner surface defining a central passage configured to supply a dielectric fluid to the machining surface. The outer surface of the tubular electrode includes at least one a channel defined therein or a non-circular cross-sectional shape.

Abstract: Various embodiments of the present technology generally relate to systems and methods for intelligent load shedding. More specifically, various embodiments of the present technology generally relate to intelligent load shedding of traffic based on current load state of target capacity. In some embodiments, a first server can send a capacity request indicating that the first server is nearing capacity and needs assistance with load. In response to the capacity request, an assistance request can be published to additional nearby servers. The servers can respond with a status update providing load and availability information. Based on the load and availability information (or other information such as latency), a second server from the additional servers can be selected and traffic can be routed away from the first server to the second server.

Abstract: Various embodiments of the present technology generally relate to systems and methods for intelligent load shedding. More specifically, various embodiments of the present technology generally relate to intelligent load shedding of traffic based on current load state of target capacity. In some embodiments, a domain name resolution request to translate a domain name into an Internet protocol (IP) address can be received at DNS server. A status of each of multiple scaling units mapped to the domain name can be determined. A set of IP addresses (e.g., four IP addresses) corresponding to a subset of the multiple scaling units closest to the requesting device with statuses indicating availability for new traffic can be identified. Then, the set of IP addresses can be sent to the requesting device. The requesting device can the select which IP address to use (e.g., randomly) to route the traffic.

Abstract: Various embodiments of the present technology generally relate to systems and methods for intelligent traffic management and routing. More specifically, various embodiments of the present technology generally relate to intelligent traffic management of cloud-based services based on predicted traffic and current load capacity of servers or scaling units. In some embodiments, traffic associated with one or more subnets can be monitored. Then using a record of historical traffic patterns and current traffic patterns, a prediction of future traffic can be generated. The predication can then be translated into an estimated load for one or more scaling units or servers. The current status of the one or more scaling units capable of handling traffic can be determined and future traffic can be routed based on the prediction generated and the status of the one or more scaling units.

Abstract: Various embodiments of the present technology generally relate to systems and methods for intelligent load shedding. More specifically, various embodiments of the present technology generally relate to intelligent load shedding of traffic based on current load state of target capacity. In some embodiments, a domain name resolution request to translate a domain name into an Internet protocol (IP) address can be received at DNS server. A status of each of multiple scaling units mapped to the domain name can be determined. A set of IP addresses (e.g., four IP addresses) corresponding to a subset of the multiple scaling units closest to the requesting device with statuses indicating availability for new traffic can be identified. Then, the set of IP addresses can be sent to the requesting device. The requesting device can the select which IP address to use (e.g., randomly) to route the traffic.

Abstract: Various embodiments of the present technology generally relate to systems and methods for intelligent load shedding. More specifically, various embodiments of the present technology generally relate to intelligent load shedding of traffic based on current load state of target capacity. In some embodiments, a first server can send a capacity request indicating that the first server is nearing capacity and needs assistance with load. In response to the capacity request, an assistance request can be published to additional nearby servers. The servers can respond with a status update providing load and availability information. Based on the load and availability information (or other information such as latency), a second server from the additional servers can be selected and traffic can be routed away from the first server to the second server.

Abstract: A computer cluster can be divided into a plurality of failure scopes and a voting constraint can be enforced. The voting constraint can allow a portion of the cluster to provide the service if a majority of health votes from cluster members is obtained by that portion. A loss of connectivity between a first failure scope, which has a majority of cluster members in the cluster, and one or more other failure scopes in the cluster can be detected. The loss of connectivity can be such that the first failure scope does not have connectivity to a member in any other failure scope in the cluster. In response to detecting the loss of connectivity, a split brain situation in the cluster can be automatically protected against by preventing the first failure scope from providing the service.

Abstract: A primary active manager can manage a first copy of a database in a first computer system cluster according to a set of management rules that provide for an active copy and one or more passive copies of the database at a given time. The primary active manager can also manage a second copy of the database in a second computer system cluster according to the rules. The rules can allow the first copy of the database or the second copy of the database to be the active copy if one or more criterion in the rules is met for that active copy. The first copy can be designated as the active copy and the second copy can be designated as a passive copy. A failure of the first copy can be detected, and in response, the second copy can be automatically designated as the active copy.

Abstract: A unified communication (UC) application integrates support actions with client communications. In response to receiving an escalation of an issue from a support technician, the UC client application initiates a communication between a responder and a target device associated with the issue. The communication is limited based on privileges of an account used to initiate the communication. A user interface component associated with the communication is provided to enable interactions with the target device. The user interface component is selected based on an instant message, an audio, a video, a remote control session, and similar modality used to communicate with the target device and additional responders. Communications associated with the issue are integrated into a communication session. A history of the session is also recorded and formatted into a timeline list. The history is provided in a subsequent issue having common attributes with the issue.

Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: Techniques to leverage replication to provide rolling point in time backup are described. Some embodiments are directed to techniques to provide rolling point in time backup with simplified restoration through distributed transactional re-creation. In one embodiment, for example, a technique may comprise creating a plurality of availability copies of a primary set of data; designating at least one of the plurality of availability copies as a backup copy; creating a log file that indicates changes to the primary set of data; updating the plurality of availability copies from the log file in near real time, without updating the backup copy; and restoring at least one of: the primary set of data and an availability copy using the backup copy and content resubmitted from a content contributor when an error occurs in at least one of: the primary set of data and an availability copy. Other embodiments are described and claimed.

Abstract: A primary active manager can manage a first copy of a database in a first computer system cluster according to a set of management rules that provide for an active copy and one or more passive copies of the database at a given time. The primary active manager can also manage a second copy of the database in a second computer system cluster according to the rules. The rules can allow the first copy of the database or the second copy of the database to be the active copy if one or more criterion in the rules is met for that active copy. The first copy can be designated as the active copy and the second copy can be designated as a passive copy. A failure of the first copy can be detected, and in response, the second copy can be automatically designated as the active copy.

Abstract: A computer cluster can be divided into a plurality of failure scopes and a voting constraint can be enforced. The voting constraint can allow a portion of the cluster to provide the service if a majority of health votes from cluster members is obtained by that portion. A loss of connectivity between a first failure scope, which has a majority of cluster members in the cluster, and one or more other failure scopes in the cluster can be detected. The loss of connectivity can be such that the first failure scope does not have connectivity to a member in any other failure scope in the cluster. In response to detecting the loss of connectivity, a split brain situation in the cluster can be automatically protected against by preventing the first failure scope from providing the service.

Abstract: Techniques to leverage replication to provide rolling point in time backup are described. Some embodiments are directed to techniques to provide rolling point in time backup with simplified restoration through distributed transactional re-creation. In one embodiment, for example, a technique may comprise creating a plurality of availability copies of a primary set of data; designating at least one of the plurality of availability copies as a backup copy; creating a log file that indicates changes to the primary set of data; updating the plurality of availability copies from the log file in near real time, without updating the backup copy; and restoring at least one of: the primary set of data and an availability copy using the backup copy and content resubmitted from a content contributor when an error occurs in at least one of: the primary set of data and an availability copy. Other embodiments are described and claimed.

Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: High availability architecture that employs a mid-tier proxy server to route client communications to active data store instances in response to failover and switchover. The proxy server includes an active manager client that interfaces to an active manager in each of the backend servers. State information and configuration information are maintained separately and according to semantics consistent with needs of corresponding data, the configuration information changing less frequently and more available, the state information changing more frequently and less available. The active manager indicates to the proxy server which of the data storage instances is the currently the active instance. In the event that the currently active instance is inactive, the proxy server selects a different backend server that currently hosts the active data store instance. Client communications are then routed to the different backend server with minimal or no interruption to the client.

Abstract: A central controlling service for datacenter activation/deactivation control in a cluster deployment to assist in preventing a split-brain scenario. The central controlling service provides a central point of control in the datacenter for application servers to periodically query as to whether to go offline, online, or normal. Redundancy of the central service facilitates detection of datacenter failure by the redundant services interacting to resolve the state of control information. This control information is then used to answer the server queries. On startup from a datacenter failure, a single instance of the central service queries other redundant instance(s) to determine if the single instance is starting up from a datacenter-wide failure or from operations other than total datacenter failure. If the failure is datacenter-wide, a central service protocol assists in resolving to the single service keeping the associated datacenter servers offline; otherwise, the server queries are answered to go online.

Abstract: Architecture that reduces data loss resulting from failover in an asynchronous log shipping deployment, but leveraging mid-tier and frontend servers to fill in lost data. In an asynchronous log shipping operation, a replication component asynchronously replicates messaging data to a backend server in accordance with one or more replication operations, which can be updates to databases on the backend server. These databases can include messaging data, such as email address books, mailboxes, etc. A history component maintains a history of replication operations on a frontend server. In the event of a lossy failover, a replay component is used for replaying the replication operations from the history to the backend server.

Abstract: Architecture that reduces data loss resulting from failover in an asynchronous log shipping deployment, but leveraging mid-tier and frontend servers to fill in lost data. In an asynchronous log shipping operation, a replication component asynchronously replicates messaging data to a backend server in accordance with one or more replication operations, which can be updates to databases on the backend server. These databases can include messaging data, such as email address books, mailboxes, etc. A history component maintains a history of replication operations on a frontend server. In the event of a lossy failover, a replay component is used for replaying the replication operations from the history to the backend server.