Articles

Systèmes distribués: le split-brain

Les systèmes distribués sont une technologie complexe qui peut présenter des risques, tels que le split-brain. Apprenons à mieux comprendre ce phénomène et à le gérer.

Le problème du Split-Brain

Split-brain can be caused by a variety of factors, including network partitions, hardware failures, or software bugs. It can also be triggered by intentional actions, such as when an administrator deliberately isolates a node from the cluster. In any case, the result is the same: two or more isolated groups of nodes, each with its own view of the data.

Real-World Example

A real-world example of split-brain occurred in 2017 when a major outage affected Amazon Web Services’ S3 storage service. The outage was caused by a network partition that split the S3 cluster into two isolated groups. As a result, some requests to the S3 service were routed to one group, while others were routed to the other group. This caused data inconsistency and led to widespread disruption.

The S3 outage serves as a reminder of the importance of testing distributed systems for split-brain scenarios. While it is impossible to completely eliminate the risk of split-brain, it is possible to reduce the impact by designing systems that are resilient to network partitions and other forms of failure.

Best Practices

When designing distributed systems, it is important to consider how the system will handle split-brain scenarios. In some cases, it may be possible to use techniques such as quorum or leader election to minimize the impact of split-brain. However, these techniques should be used with caution, as they can introduce additional complexity and overhead.

In general, the best approach is to design systems that are resilient to network partitions and other forms of failure. This can be achieved by using techniques such as replication, redundancy, and fault tolerance. It is also important to test distributed systems for split-brain scenarios before they are deployed in production.

Le problème du Split-Brain

Dans les systèmes distribués, il est essentiel de maintenir une vue cohérente des données sur tous les nœuds pour un fonctionnement correct. Lorsqu’un scénario de split-brain se produit, chaque groupe partitionné peut recevoir des mises à jour différentes, ce qui entraîne une incohérence des données et rend difficile la résolution des conflits lorsque les partitions se reconnectent finalement.

Le split-brain peut être causé par une variété de facteurs, notamment des partitions réseau, des pannes matérielles ou des bogues logiciels. Il peut également être déclenché par des actions intentionnelles, telles que lorsqu’un administrateur isole délibérément un nœud du cluster. Dans tous les cas, le résultat est le même : deux ou plusieurs groupes isolés de nœuds, chacun ayant sa propre vue des données.

Exemple concret

Un exemple concret de split-brain s’est produit en 2017 lorsqu’une panne majeure a affecté le service de stockage S3 d’Amazon Web Services. La panne était causée par une partition réseau qui a divisé le cluster S3 en deux groupes isolés. En conséquence, certaines demandes au service S3 ont été acheminées vers un groupe, tandis

Source de l’article sur DZONE

PlatformCréer un client de secours avec Hazelcast Viridian Platform sans serveur

Vous pouvez facilement créer un client de secours avec Hazelcast Viridian Platform sans serveur, ce qui vous permet d’accéder à des données et services à tout moment.

Mise en place d’un client de basculement pour une stratégie de reprise après sinistre

En tant que scientifique informatique enthousiaste, je sais que le failover est une fonctionnalité importante des systèmes qui dépendent d’une disponibilité quasi constante. Dans Hazelcast, un client de failover redirige automatiquement son trafic vers un cluster secondaire lorsque le client ne peut pas se connecter au cluster primaire. Il est conseillé d’utiliser un client de failover avec la réplication WAN comme partie intégrante de votre stratégie de reprise après sinistre. Dans ce tutoriel, vous mettrez à jour le code d’un client Java pour qu’il se connecte automatiquement à un cluster secondaire de failover s’il ne peut pas se connecter à son cluster primaire d’origine. Vous effectuerez également un test simple pour vous assurer que votre configuration est correcte et l’ajusterez ensuite pour inclure la gestion des exceptions. Vous apprendrez comment recueillir toutes les ressources dont vous avez besoin pour créer un client de failover pour un cluster primaire et secondaire, créer un client de failover basé sur le client Java d’exemple, tester le failover et ajouter la gestion des exceptions pour les opérations.

Étape 1: Configurer les clusters et les clients

Créez deux clusters Viridian Serverless que vous utiliserez comme clusters primaires et secondaires, puis téléchargez et connectez des clients Java d’exemple à ceux-ci.

Une fois que vous avez créé les clusters et les clients, vous devez créer une base de données qui contient les informations sur les clusters primaires et secondaires. Cette base de données doit être accessible à partir du client Java afin qu’il puisse accéder aux informations relatives aux clusters primaires et secondaires. Vous pouvez créer cette base de données en utilisant n’importe quel type de base de données relationnelle ou non relationnelle. Une fois que vous avez créé la base de données, vous devez y ajouter les informations sur les clusters primaires et secondaires. Vous pouvez également ajouter des informations supplémentaires telles que l’adresse IP du cluster primaire et secondaire, le port utilisé par le cluster, le nom du cluster, etc.

Une fois que vous avez créé la base de données et ajouté les informations sur les clusters primaires et secondaires, vous pouvez maintenant configurer le client Java pour qu’il puisse accéder à cette base de données et récupérer les informations nécessaires. Pour ce faire, vous devez ajouter le code nécessaire à votre client Java pour qu’il puisse se connecter à la base de données et récupérer les informations nécessaires. Une fois que vous avez terminé cette étape, votre client Java est prêt à être utilisé pour se connecter aux clusters primaires et secondaires.

Source de l’article sur DZONE

This article will demonstrate the heterogeneous systems integration and building of the BI system and mainly talk about the DELTA load issues and how to overcome them. How can we compare the source table and target table when we cannot find a proper way to identify the changes in the source table using the SSIS ETL Tool?

Systems Used

  • SAP S/4HANA is an Enterprise Resource Planning (ERP) software package meant to cover all day-to-day processes of an enterprise, e.g., order-to-cash, procure-to-pay, finance & controlling request-to-service, and core capabilities. SAP HANA is a column-oriented, in-memory relational database that combines OLAP and OLTP operations into a single system.
  • SAP Landscape Transformation (SLT) Replication is a trigger-based data replication method in the HANA system. It is a perfect solution for replicating real-time data or schedule-based replication from SAP and non-SAP sources.
  • Azure SQL Database is a fully managed platform as a service (PaaS) database engine that handles most of the management functions offered by the database, including backups, patching, upgrading, and monitoring, with minimal user involvement.
  • SQL Server Integration Services (SSIS) is a platform for building enterprise-level data integration and transformation solutions. SSIS is used to integrate and establish the pipeline for ETL and solve complex business problems by copying or downloading files, loading data warehouses, cleansing, and mining data.
  • Power BI is an interactive data visualization software developed by Microsoft with a primary focus on business intelligence.

Business Requirement

Let us first talk about the business requirements. We have more than 20 different Point-of-Sale (POS) data from other online retailers like Target, Walmart, Amazon, Macy’s, Kohl’s, JC Penney, etc. Apart from this, the primary business transactions will happen in SAP S/4HANA, and business users will require the BI reports for analysis purposes.

Source de l’article sur DZONE

For the past few years, business systems have been generating large amounts of data and need tools to manage the data. One of the business requirements was to copy the primary data to secondary databases. Several popular tools are available in the market to replicate the data from master DB to secondary DB. This article will discuss various open-source tools for DB replication and stream-based replication for real-time.

Replication is the process of sharing/storing information in multiple places to ensure reliability, fault tolerance, and accessibility. The replication options are described as follows:

Source de l’article sur DZONE


Introduction 

In our previous article, we discussed two emerging options for building new-age data pipes using stream processing. One option leverages Apache Spark for stream processing and the other makes use of a Kafka-Kubernetes combination of any cloud platform for distributed computing. The first approach is reasonably popular, and a lot has already been written about it. However, the second option is catching up in the market as that is far less complex to set up and easier to maintain. Also, data-on-the-cloud is a natural outcome of the technological drivers that are prevailing in the market. So, this article will focus on the second approach to see how it can be implemented in different cloud environments.

Kafka-K8s Streaming Approach in Cloud

In this approach, if the number of partitions in the Kafka topic matches with the replication factor of the pods in the Kubernetes cluster, then the pods together form a consumer group and ensure all the advantages of distributed computing. It can be well depicted through the below equation:

Source de l’article sur DZONE

MySQL semi-synchronous is a plugin mechanism on top of asynchronous replication that can offer better durability and even consistency. It helps in high availability solutions, but can in itself reduce availability. In this article, we will look at some basics and follow up to present scenarios requiring higher-level intervention to ensure availability and avoid split-brains.

Overview

As a quick recap, semi-synchronous replication is a mechanism where a commit on the primary does not apply the change onto the internal table data and does not respond to the user until the changelog is guaranteed to have been persisted (though not necessarily applied) on a preconfigured number of replicas. We limit our discussion to MySQL 5.7 or equivalent.

Source de l’article sur DZONE

NoSQL data sets arose in the latter part of the 2000s as the expense of storage drastically diminished. The days of expecting to create a complicated, hard to-oversee data model to avoid data replication were long gone and the primary expense of programming and development was now focused on the developers themselves, and hence NoSQL databases were brought into the picture to enhance their productivity.

As storage costs quickly diminished, the measure of data that applications expected to store increased, and the query expanded as well. This data was received in all shapes and sizes — organized, semi-organized, and polymorphic — and characterizing the schema ahead of time turned out to be almost incomprehensible. NoSQL databases permitted the developers to store colossal measures of unstructured data, providing them with a ton of flexibility. 

Source de l’article sur DZONE

PostgreSQL is an open-source, versatile, and most popular database system around the world. However, it does not have any features for high availability.

Enter Patroni.  Patroni is a cluster manager tool used for customizing and automating deployment and maintenance of high availability PostgreSQL clusters. It is written in Python and uses etcd, Consul, and ZooKeeper as a distributed configuration store for maximum accessibility. In addition, Patroni is capable of handling database replication, backup, and restoration configurations.

Source de l’article sur DZONE

Hybrid cloud architectures are the new black for most companies. A cloud-first is obvious for many, but legacy infrastructure must be maintained, integrated, and (maybe) replaced over time. Event Streaming with the Apache Kafka ecosystem is a perfect technology for building hybrid replication in real-time at scale.

App Modernization and Streaming Replication With Apache Kafka at Bayer

Most enterprises require a reliable and scalable integration between legacy systems such as IBM Mainframe, Oracle, SAP ERP, and modern cloud-native applications like Snowflake, MongoDB Atlas, or AWS Lambda.

Source de l’article sur DZONE

Le 7 Octobre 2020 SAP a annoncé la disponibilité générale de SAP S/4HANA 2020 :  la sixième version de SAP S/4 HANA vient d’apparaitre avec toujours plus d’innovations à la clé.

Avec la version 2020 de SAP S/4HANA on poursuit la logique d’innovation continue avec des nouveautés fonctionnelles disponibles sur l’ensemble des processus finance.

Ces nouveautés sont immédiatement opérationnelles et disponibles lors de la sortie de la nouvelle version On Premise car elles ont été préalablement implémentées et testées depuis des mois dans la version Cloud de SAP S/4HANA.

Le document What’s new in SAP S/4HANA 2020 récapitule de façon exhaustive toutes les nouveautés apportées par cette version dans les différents domaines de la solution. Cette nouvelle version comporte des centaines d’innovations uniquement dans le domaine de la Finance et il est impossible de toutes les présenter ici. A titre d’illustration, nous vous proposons de passer en revue quelques-unes des nouveautés les plus remarquables :

Par exemple, dans le domaine de la comptabilité générale et bancaire, la nouvelle version réduit l’utilisation des comptes généraux, notamment des comptes bancaires, en simplifiant les processus de gestion des relations bancaires. L’utilisation des mêmes ensembles de comptes de rapprochement bancaire et de comptes d’attente pour la connectivité de la banque société réduit considérablement le nombre de comptes généraux requis pour les processus de paiement. Cette méthode offre également l’avantage de faciliter la gestion du plan comptable.

Dans le domaine de la clôture financière, avec SAP S/4HANA for Group Reporting, les équipes de consolidation peuvent générer simultanément des résultats dans plusieurs devises du groupe dans un seul processus de clôture. Ceci améliore l’efficacité et l’automatisation lorsque vous travaillez avec différentes devises dans le  groupe ou plusieurs taux de conversions de devise, par exemple pour une conversion à taux de change constants pour le reporting comparatif.

 

 

Dans la gestion des Clients et le contrôle de Crédit, un ensemble d’états de reporting avancés a été développé sur SAP Analytics Cloud avec pour objectif de donner les moyens au crédit manager d’améliorer le pilotage du contrôle crédit.  Ces états de reporting, nativement intégrés dans SAP S/4HANA, sont alimentés en temps réel par les flux des ventes et ouvrent la possibilité d’effectuer du drill-down vers les transactions opérationnelles.

 

 

Dans ce même domaine, une autre innovation réside dans la création d’une application Fiori qui donne accès à un cockpit de pilotage permettant une vue à 360° de toutes les informations nécessaires au contrôle crédit d’un partenaire donné. On peut ainsi accéder depuis un même endroit aux information générales sur le profil de crédit, des informations par segment et leurs limites et taux d’utilisation, une balance âgée synthétique, les commandes en attente d’approbation et même des informations sur des assurances ou garanties collatérales éventuelles. La navigation est ainsi grandement facilitée, les informations clés regroupées et disponibles de façon rapide, souvent dans un format graphique : voici un bel exemple d’innovation mise en œuvre pour faciliter l’adoption de la solution et assurer la meilleure expérience possible à l’utilisateur.

La plateforme SAP Central Finance a été optimisée dans la version SAP S/4HANA 2020 avec la mise à disposition de solutions d’intégration développées avec Magnitude dans le cadre du partenariat Solution Extension :

  • SAP Central Finance Data Harmonization by Magnitude
  • SAP Central Finance Transaction Replication by Magnitude

 

 

Central Finance permet la réplication des transactions des opérations issues de différentes sources dans une instance unique SAP S/4HANA, ce qui génère d’importants avantages liés à la centralisation, par exemple dans le cadre du reporting,  la comptabilisation des allocations, les opérations inter-sociétés ou la mise en place et opération de centres de services.

Ces nouvelles solutions d’intégration permettent de faciliter et d’accélérer l’intégration des données tout en fiabilisant le processus et en réduisant le TCO de Central Finance.

Deux autres innovations remarquables dans Central Finance :

  • La fonctionnalité de ventilation à la pièce est désormais disponible dans Central Finance et ceci même lorsque les systèmes SAP source n’en disposent pas.
  • Concernant le contrôle budgétaire, le budget des ordres internes peut être géré désormais de manière centrale dans SAP Central Finance grâce au suivi de la consommation de celui-ci dans les systèmes sources.

En conclusion, la version 2020 de SAP S/4HANA comporte une grande quantité de nouveautés qui méritent d’être découvertes lors d’une prochaine formation chez SAP France.


Voici le lien vers le calendrier des formations de H1 2021 afin de choisir celle qui vous convient le plus. Vous pouvez aussi avoir un aperçu des formations susceptibles de vous intéresser à l’aide des différents parcours de formation détaillés dans les  Learning Journeys mis à votre disposition par SAP Training and Adoption France.


 

The post Quoi de neuf dans la Comptabilité Financière avec la release SAP S/4HANA 2020 ? appeared first on SAP France News.

Source de l’article sur sap.com